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ABSTRACT 



A computer system for modeling is disclosed, where the 
computer system has a storage device, first and second 
platforms, a portable persistent model, and first and second 
platform-dependent computerized modeling systems 
(CMS). Each platform is interfaced to the storage device and 
provides system-dependent services. The first platform has a 
first type of operating system and a first type of computer 
hardware including a first memory, and the second platiOorm 
has a second type of operating system and a second type of 
computer hardware including a second memory. The model 
resides in the storage device in a platform-independent 
format and includes persistent component objects. Hie first 
CMS resides in the first platfomilmemory and the second 
platform-dependent CMS resides in the second platform 
memory. Each CMS provides CMS services including 
retrieving the model from the storage device, manipulating 
the model, changing the model by adding and removing 
persistent objects, and persistently saving the model to the 
storage device. Each CMS includes a static kernel and a 
dynamic fi-amework. The kernel executes on the platform 
and interfaces to the operating system and the computer 
hardware, and provides services necessary to load and 
execute CMS services and to interface to the platform 
services. The framework executes on the platform and 
interfaces to the kernel, provides a platform-independent 
visual interface between the CMS and a CMS user, and 
employs the services of the kernel. 

24 Claims 17 Drawing Sheets 



PROJECT O-'l^ 




KERNEL 



IE 



22 



OPERATING SYS. 
GRAPHICS SYS 




01/08/2004, EAST Version: 1.4.1 



6,063,128 

Page 2 



OTHER PUBLICAnONS 



Gunaseelan, L.; LeBlanc. R. J., Jr.; "Distributed Eiffel: A 
Language for Programming Multi-granulr Distributed 
Objects on the Clouds Operating System", Proceedings of 
the 1992 International Conference on Computer Languages, 
pp. 331-340, Apr. 1992. 

Sommer, J.;"The DaCapo Project: Distributed, Active, Com- 
municating, Persistent Objects", Proceedings of the Second 
International Workshop on Object Oriented in Operating 
Systems, pp. 129-132, Sep. 1992. 



Ben-Shaul, L; Cohen, A.; Holder, O.; Lawa, B.;"HADAS: 
A Network Centric Framework for Interoperability Pro- 
gramming", Prooeeding3 of the Second IFCIS International 
Conference on Cooperative Information Systems, pp. 
120-129, Jul. 1997. 

Bottgeret al., "An Object-Oriented Model for Specification, 
Prototyping, Implementation and Reuse", Proceedings of 
the Design, Automation and Test in Europe, 1998, pp. 
303-310, Feb. 1998. 

MicroStalion J Whitepaper, downloaded from the internet at 
http://www.bentley.eom/products/mstation/j/msjwhite.pdf. 
MicroStation J News Release, downloaded from the intemet 
at http://www.bentley.coai/news/beadline/msjships.htm. 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 1 of 17 



6,063,128 



PERSISTENT 
STORE 1 





PROJECT 
D&TABASE 



PERSISTENT 

STORE 2 



18 



PERSISTENT 
STORE N 



FRAMEWORK 




2: 



ho 



1 



KERNEL 



J. 



-12 



OPERATING SYS. 
GRAPHICS SYS 




FIG. 1 



PROJECT 
SCHEMA 



'50 



10 



DEFAULT 
MODELING 
SCHEMA 

io 



DEFAULT 
DRAFTING 
SCHEMA 



COMPATIBILITY 

SCHEMAS 
(DGN/OWG) 

^ 



DISCIPLINE 
SPECIFIC 
SCHEMAS 



50 MODEL 



16 



TRANSACTION 
MANAGER 



COMMAND 

TOOL 
MANAGER 

1 

44 



GRAPHICS 
AGENTS/ 
PIPELINE 



40 



PORTABLE 

GUI 
TOOLKIT 



OTHER 
SUBSYSTEMS 



48 



FRAMEWORK 



VIRTUAL 
MACHINE 



l4 



OBJECT/ 
PERSISTENCE 
MANAGER 









SYSTEM 




OTHER 




SUPPORT 




GUI 




DYNAM IC 




LIBRARIES 




JNT*FACE 




, MODULES 



FIG. 2 



2^ 
"^2" 



KERNEL 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 2 of 17 



6,063,128 



4- 



32 



SYSTEM 
STATE 
OBJECT 



0..N 



SYSTEM 
EVENT 
RES PONDER 



0..N 



WINDOW y 



36 



4- 



0-N 
38 



VIEWPORT 



GRAPHICS 
AGENT 




FIG. 3 



18 



.52 



DISCIPLINE 
SPECIFIC 
OBJECT 



-50 



.50 



DISCIPUNE 
SPECIFIC 
SCHEMA 



PROJECT 




SCHEMA 





50 



DGN/DWG 
COMPATIBILITY 
SCHEMAS 





OGN 




ELEMENT 



52 



DISCIPLINE 
SPECIFIC 
OBJECT 



,52 



OBJECT 



50 



MODELING 
SCHEMA 



z 



DRAFTING 
SCHEMA 



--50 



PERSISTENT STORE 



FIG. 4 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 3 of 17 



6,063,128 



54n 



CLASS 1 



MEMBER . -60 
VARIABLES 



METHODS 



1 r 



'62 



5^ 



CLASS n 



MEMBER 
VARIABLES 



METHODS 



56- 



56- 



INTERFACE 1 



METHODS 62 



INTERFACE n 



METHODS 



58- 



TEM PLATE 1 



CLASS 



MEMBER 
VARIABLES 



METHODS 



58^ 



TEMPLATE 2 



INTERFACE 



METHODS 



PROGRAMMING CODE 



1 



N 



CLASS 1 



MEMBER 
VARIABLES 



METHODS 



^54 



60. 



62' 



CLASS n 



. MEMBER 
VARIABLES 



METHODS 



.54 



62- 



INTERFACE 1 



METHODS 



56 



INTERFACE n 



METHODS 



56 



60 



62-a 



CLASS Tl 



MEMBER 
VARIABLE 



METHODS 



54 



CLASS T2 



MEMBER 
VARIABLES 



METHODS 



54 



COMPILER 



62- 



INTERFACCTI 



METHODS 



56 



INTERFACET2 



METHODS 



56 



SCHEMA 



53 



^5 

FIG. 5^ 



•50 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16, 2000 sheet 4 of 17 6,063 



52C 



CLASS DECLARATION 




\ 


• • • 





64 




METHOD 



.62 

METHOD -+-62 



INSTANCE DATA DERNmON INSTANCE METHODS 

FIG. 6 



521 



INTERFACE DECLARATION 






• • • 





-66 



METHOD 



METHOD 



.62 



INSTANCE METHODS 

FIG. 7 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16, 2000 sheet 5 of 17 



6,063,128 



68 



1 



HANDLE 



52 



OBJECT DESCRIPTOR 1 








• • • 





-70 



74 

M 



INSTANCE DATA 
REFERENCE 



72 



Vi 



7 



CLASS 
REFERENCE 



INSTANCE DATA 
X OI23 



100 

62 



.76 



CLASS OBJECT 



INSTANCE DATA 
DEFINITION 



52C 



CLASS METHODS 



80 



BACKPOINTERS 



OBJECT DESCRIPTOR 2 








• • • 






FIG. 8 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16, 2000 sheet 6 of 17 6,063,128 



RETRIEVE CLASS0F0BJECTh >S9l 



S92 




M 



ATCH I 



NO match"! 



SPECIFIED^ '''^ »| MATCH 



FIG. 9 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 7 of 17 



6,063,128 



84 



GLOBAL TABLE 



NAME 


SELECTOR 


METHOD 1 


1 


METHOD 2 


2 


METHOD 3 


3 


• 
• 
• 


• 
• 
• 


METHOD N 


N 



( 

82 



/ 

84 



FIG. 10 



TOP 



1 




2 


B 


3 




4 




5 




6 




7 




8 




9 


a- 


10 




11 




12 




13 




• 




• 




• 




256 





MIDDLE 



1 




2 




3 




4 


1 


5 




6 




7 




8 




9 


B- 


10 




11 




12 




13 




• 




• 




• 




256 





1 




2 




• 
• 
• 

16 





BOTTOM 



B-2 



1 




2 




• 
• 
• 
• 




16 





1 




2 




• 
• 
• 




16 





B-2-1 



B-9 

\ 

84B 
84D 

/ 

D-9 
I 



1 




2 




• 




• 




• 




• 




16 





T 
B-9-2 



D-9-2 



1 




2 




• 
• 
• 




16 





1 


2 


a, 


• 




• 




• 




16 



7 

D-13 



1 




2 




• 




• 




• 

• 




16 




D-13-2 


1 




2 




• 
• 
• 




16 





01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16, 2000 sheet 8 of 17 



6,063,128 



STATICALLY 
ALLOCATED 
OBJECT 

52S 



STATICALLY 
ALLOCATED 
OBJECT ^ 



OBJECT 52 



TEMPORARY 
OBJECT DESCRIPTOR 



70T 


OBJECT 


DESCRIPTOR 


70 










■ • • • 







ALLOCATION FLA6l= 1 ~1 ~86 | ALLOCATION FLAG » q"~V 86 



FIG. 11 



52 



OBJECT DESCRIPTOR 1 













z 



70 



INSTANCE DATA 
x>123 



101 



72 \ 88 \ 102 

^ ^ , , ^ ^ , 

DIRTY BIT° 1 i {CHANGE BIT ° 1 j 



52 



OBJECT DESCRIPTOR 2 













70 



72 



.88 



INSTANCE DATA I | DIRTY^T° 1 | 



^102 
CHANGE BIT""~n 



FIG. 12 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 9 of 17 



6,063,128 



REGISTER 1 



REGISTER 2 



REGISTER 3 



REGISTER N '-'SO 




VIRTUAL MACHINE STACK 



LOCATION 1 



LOCATION 2 



LOCATION 3 



LOCATION N 



NATIVE CODE STACK 



FIG. 13 



55 



PROGRAMMING 
LANGUAGE 
SOURCE CODE 



PLATFORM 1 



VIRTUAL 
MACHINE 1 



■A- 



19 



24 



-55 



COMPILER 



PLATFORM 2 



VIRTUAL 
MACHINE 2 

^24 



19 



Fl G. 1 4 



96 



PROGRAM/ 
APPLICATION 
[P-CODE] 




PLATFORM N 



VIRTUAL 
MACHINE N 



^24 



19 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16, 2000 Sheet 10 of 17 6,063,128 



98c 



a: 



-V— 

98q 



98c 

Fl G. 15 



98b 



J 



980 98b 98a 98b 98a 98b 98a 98b 98a 98b 98g 9jBb 98a 98b 




98q 98b 98b 98b 98a 98b 98b 98b 98b 



Fl 6. 16 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16,2000 Sheet 11 of 17 6,063,128 



COMPILE LIST OF OBJECTS 
FOR VAUDATION 



1^ 



1701 



VAUOATE FIRST OBJECT \ ^ 



I 



CLEAR OBJGCrCHANGE 
BIT 



I 



SEND CHANGE NCmFlCATlONl-^ 
TO DEPENDENT OBJECTS 



S1702 
S1703 



S1704 



S1707 




SI7O6 

VALIDATE NEXT OBJECT | 



ITERATE WAVE 
COUNTER 



.S1709 




NOTIFY 
USER 



-S1710 



FIG. 17 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16,2000 Sheet 12 of 17 6,063,128 



OBJECT 


DESCRIPTOR 













104 



^52 



PERSISTENCE BINDING 
TAG REFERENCE 




PERSIST 


ENCE BINDING TAG 




N 









TAG to. 



^08 



PERSISTENT STORE 
REFERENCE 



FIG. 18 



_Z__./18 
PERSISTENT y 



STORE 



106- 

n 
no 



BACK-POINTORS 



-J&O 



iaG3 



— EBG 



■^72 



PERSISTENT STORE 



52 C 



\ 



18 



f 



70 



CLASS OBJECT DESCRIPTOR 













106 



110 ^ 



PERSISTENCE TAGS^ 










r 



INSTANCE DATA 




OBJECT DESCRIPTOR^ 1 














,106 



PERSISTENCE TAG 




1A63 







no 



OBJECT DESCRIPTOR 2 














/JO 



FIG. 19 



PERSISTENCE TAG 




1AG2 







^106 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 13 of 17 



6,063,128 



FILE 1 
IDENTIFIER 1 



S12 
il4 



PROJECT 
OBJECT 



'52P 



STORE \ 

( ROOT STORE) 



■18R 



16 



/ 



FILE 2 
IDENTIFIER 2 



STORE 2 



-112 
M14 



FILE N 
IDENTIFIER N 



-112 
.>114 



STORE N 



•18 



PROJ ECT DATA BASE 

^ 



18 



FIG. 20 



17 



52 



POTENnAL 



OBJECT CLASS INSTANCE REFERENCE OBJECTS 
DESCRIPTOR INSIALIED DATA CONNECTED TO 



CONNECT NO 



NO 



OBJECT 



^^"nJnon-rescent 



OBJECT 



DISCARD. 




YES 



YES 



NO 



NO 



NO 



NO 



resident 
08jktJ^52 



FAULT 



YES 



YES 



YES 



YES 



FIG. 21 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 14 of 17 



6,063,128 



INSTANCE DATA] 
x»123 



v=I.O 
U 456 



52 



70 



72 
h72A 



OBJECT DESCRIPTOR 













\Q0 



-HCLASSi 
54 



FIG. 22 



lOOA 



DATA OEFINITION 

INT X 
OBJECT*p 



AUXDAIAOEFINrnON 



DOUBLE V 



LONG 



I 




116 



52R 



OTHER 
WEB 
PAGE 



NETWORK 
^118 



122-^ URL 



124 FLAGS 



M20 
'22fL0CAL 
12^ 

122 
124 



FLAGS 
^120 



LOCAL 



122 



FLAGS 
>120 



124 



URL 



FUGS 



ACME 
WALL 



MY 
WINDOW 



OTHER LOCAL 
CLASS 



OTHER REMOTE 
CLASS 



USER CMS 




•lOU 



Fl 6. 23 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent 



May 16, 2000 



Sheet 15 of 17 



6,063,128 




o 

z ¥ 
UJ < 

o 
z 
u 







CO 


VIRTUAL 
MACHINE 


DATA SERVER 


COMPONENT 
MANUFACTURER 
DATABASE 



'Z 



00 
CM 



01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16,2000 



Sheet 16 of 17 



6,063,128 




01/08/2004, EAST Version: 1.4.1 



U.S. Patent May 16,2000 Sheet 17 of 17 6,063,128 



BASE 


*oBase; 


Derived 


*oArray[10]; 


char 


*pName; 


pName = 


oArray[oBase->inclex]-.m_pName; 




01/08/2004, EAST Version: 1.4.1 



6,0( 

1 

OBJECT-ORIENTED COMPUTERIZED 
MODELING SYSTEM 

ITiis is a division of application Ser. No. 08/612,622, 
filed Mar. 6, 1996, now U.S. Pat. No. 5,815,415. This 
application claims benefit of provisional application 60/010, 
234 filed Jan. 19, 1996. This application claims benefit of 
provisional application 60/011,285, filed Feb. 7, 1996. 

HELD OF THE INVENTION 

The present invention relates to a system for computer- 
ized modeling. More particularly, the present invention is 
related to an object-oriented computerized modeling system 
that is employed to construct a model from component 
objects and the like and to persistently save and recall the 
constructed model. 

BACKGROUND OF THE INVENTION 

A typical computer-aided design ("CAD") system 
employed in engineering contexts uses a geometry-oriented 
approach to define and represent engineering information, 
llie data is generally stored in a large set of geometrically 
organized files with links to external non-graphical data. The 
format and content of the files are predefined by the CAD 
system, with all of the data types known to the system 
compiled into the program. 

Such an approach has the advantage of uniformity and 
predictability between system users from different engineer- 
ing domains. In a system implemented with great attention 
to hardware and version compatibility, data files created with 
one version of the CAD system can be viewed by other 
versions of the same CAD system regardless of hardware 
platform. The approach works well for creating 2D drawings 
and 3D models of the physical properties of a design, but 
lacks the sophistication and flexibility to maintain the 
structure, topology, and additional attributes or descriptive 
information that accompany a complete engineering model. 
Furthermore, multi-platform and multi-version software 
support is a serious burden for both the original producer of 
the CAD system and for others that add customized exten- 
sions. 

To properly model a complex design, engineering or 
otherwise, a computerized modeling system ("CMS"*) must 
represent not just the geometric properties of a model, but 
also the domain-specific relationships between components 
in the design and tacit information about the model that 
arises during the development of the model. However, the 
most efficient strategy for organizing and storing model 
information does not always correlate with the geometric 
properties of the information. 

Further, since the data types expressed in an engineering 
model vary widely between engineering domains (electrical, 
mechanical, fluids, e.g.), it is not practical to express all of 
the possible combinations of data types within the program 
that operates the CMS. Moreover, since model data from 
differing domains may be simultaneously required in arbi- 
trary combinations by a user, multiple, unrelated domain- 
specific tools cannot be employed. 

CMS Requirements 

A CMS must solve the problem described above by 
providing flexible programming tools that allow a software 
developer having engineering domain-specific expertise to 
develop programs and data structures ("schemas") relevant 
to any such domain. A user of the CMS employs one or more 
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such schemas, whereby representations of domain-specific 
components (''objects") derived from the schemas can be 
combined and integrated in arbitrary combinations in con- 
nection with a single project. 

^ To accomplish such a goal, the CMS must address the 
following concerns: 
Data Portability and Longevity 
In large organizations, engineering groups often woric on 
multiple different types of mixed hardware and operating 
system configurations ("platforms"). Moreover, the life 
cycles of a larger project will often exceed the lifetime of 
one or more of such platforms. Accordingly, it is essential 
that CMS data that originates on one platform be useable on 

j5 any other platform without translation. As a resuh, the CMS 
does not constrain an otherwise natural progression to the 
most cost effective computer systems. Furthermore, a 
project defined by such CMS data can be archived and 
reactivated years later on a new platform without any loss of 

2Q fidelity. 

Similarly, the type and meaning of the information in a 
project can change dramatically throughout the project life 
cycle. For example, data for a particular component may 
change several times during the project life cycle, usually 

25 because the manufacturer of the component modified the 
component or replaced the component with a similar or 
related component. It must therefore be possible to refine 
and revise the schemas that are used by the project (i.e. allow 
^'schema evolution") without jeopardizing the integrity of 

30 the abready-existing CMS data. 
Data Integrity 

A CMS stores a tremendous amount of valuable informa- 
tion. However, the value of the information can only be 
secure if models created by the program are accurate, 

35 reliable, and accessible. To ensure the data in a CMS model 
maintains internal consistency, it is necessary that such data 
always be accessed and modified by the same schemas that 
defined and created such data. It is therefore essential that 
such schemas be easily accessed and ubiquitous with respect 

40 to the CMS model. Moreover a CMS must minimize the 
need to produce and distribute copies of CMS models. As 
should be evident, when multiple copies of the same model 
exist, any individual copy stands a greater chance of being 
rendered partially or wholly obsolete. 

45 Large Data Sets 

The size of a typical CMS model can be quite large, on the 
order of several hundred megabytes. The CMS must handle 
such large models efficiently. Further, the amount of infor- 
mation in a model cannot be limited in a preset manner. 
Many Simultaneous Users 

CMS models arc typically shared simultaneously by 
many users within an organization. Some users require 
access for inspecting and querying only, but others need 
35 access to add to or modify the model. Accordingly, the CMS 
must ensure that changes to the model are properly coordi- 
nated and thai the model is kept in a consistent state at all 
times. 

Many Simultaneous Schemas 

60 Engineering projects typically involve collaboration 
among several engineering disciplines, each being repre- 
sented by one or more CMS schemas. A CMS is expected to 
facilitate the integration of the information created by each 
discipline to allow easy and consistent access by users in the 

65 other disciplines. Therefore, a CMS must store and manipu- 
late information defined by muhiple schemas simulta- 
neously. Further, it must be possible for one schema to 
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reference information defined in and maintained by another Change Propagation 

schema within the project and that reference must be kept When an object in a model is modified, other objects in 

consistent throughout the project life cycle. the model may change as a result. A CMS must express 

Flexibility and Extensibility relationships between objects such that the need for effecting 

A CMS is typicaUy refined by a developer based on the ^ changes to objects "downstream" may be recognized, 

domain that the developer is directed toward. Additionally, propagated, and executed. In addition, if such propagation 

a CMS is refined by the end user to include user-defined ^^^^1^ "^^^^^ ^r inconsistent state of the model, the 

restrictions and extensions. Since every user has different ^^^^^^ ^^^"g^ ™^st be reversed, 

requirements, the ability to extend and customize the system Model Persistence 

"in the field" is essential. State information for objects in a model must be main- 
Performance tained across editing sessions. Accordingly, the objects must 
Engineering modek in particular are characterized by be dynamicdly reinstated each time the CMS is used lo view 

, J , , J J ... or manipulate the model. 

large data sets, yet users demand near-mstantaneous . 

response times. A CMS must therefore be able to organize 15 Model Management 

and store data such that access time to the data is optimized. ^ CMS must mamtam the integrity of a model. 

Ease of Use Accordingly, mechanisms are required to: lock portions of 

^ , . . . . , , the model to regulate multi-user access; control revision 

A CMS user is presumed to be an expert m his domain. ^^^^^^ ^ ^^,,^1 development to the same 

However,heisnot necessarUyasophi^^^^^^ ^^^^j. ^^^^ ^^j^. 

and IS likely not willmg to mvest valuable time m extensive 20 ^^^^j. permanently identify specific versions of constituent 

framing. Furthermore, smce muUiple users from different models of a project as contributing to a particular state of the 

domains wUl employ the same CMS the domam-specific ^^j,^^. , j^j^ ^^^^ ^^^^^ according to 

expertise of the users will vary widely from session to graduated security levels. 

session. Accordingly, use of a CMS must be simple. Distributed Com onents 

intuitive, and familiar, and the schemas employed by a CMS 25 ° ponen 

must be flexible enough to aUow access to schema data at , ^? ^^^P Prevent data obsolescence, a CMS must allow for 

various levels of detail and complexity depending on the havmgportions of the model distnbuted out to those parts of 

/ 1- o an organization (or remote vendor locations, subcontractors, 
etc.) where they are most easily maintained. At the same 

CMS Implementation 30 Itme, a ''live connection" to the distributed portion must be 

^. f .r>**o . maintained in each model where it is referenced. 

Given the foregomg CMS requirements, a successful * • • . • j , 1 

CMS must incorporate a robust environment for program- . ^ T"^"' iS^.xT. '^'^I'"^ a computerized model- 

mers to implement schemas. and an easy-to-use environ- !°f ^^^^ <™ } electronically models engmeermg 

mem for users to employ those schemas on real world '"f™"" for design. analysB. manipulation, simulatton 

problems. To that end. the CMS implementation must vi^ializat^n. integration, decomposition, storage and 

l^^j^^g. ^ retrieval. The present invention is highly suited for engi- 

^ ' neering environments such as mechanical engineering; 

actiema Environment structural engineering; elecuical engineering; civil and road- 

Schemas must contain all necessary information to way engineering; plant design, layout, and operation; build- 
display, manipulate, query, revise, and interpret a model; ^ ing engineering and construction; facilities planning and 
there can not be any application-specific expertise built into maintenance; mapping; and geo-engineering; among other 
the CMS itself. Schemas must be portable so that they can things. 

execute on any platform that the CMS can execute, be ^o address the requirements discussed above, the pre- 

mseparable from the project model, be flexible and expand- ^^^^^ embodiment of the present invention includes an 

able without requiring the origmal schema source c^^^ ^3 object-oriented schema implementation programming 

recompilauon and execute efficiently. Due to the large j^^g^^^,^ ^ compiler, a linker, and a run-time system. Hie 

quantity of information modeled by a CMS, the routines that programming language is largely based on the C and C++ 

process such mformation must do so in an efficient manner. programming languages with certain CMS extensions as 

Schemasmustalsobeablctoevolveovertimesuchthatthey 5, described below, and is employed to write schema 

can be revised and extended as new requirements arise. programs that are compiled using the compiler. The output 

Apphcation Framework of the compiler is an object file. The Unker combines a group 

The geometric tools (location, manipulation, creation, of object files into an executable program that is portable 

display, visualization, vector algebra, etc.) for manipulating across many platforms, where each platform has a run-time 

schema objects must be presented to the user in a familiar environment tailored to that platform. Each program may 

and casy-to-usc environment, or "application framework". 55 alsobcasharcdlibrary. If so, the program exports references 

llie user interface programs must be portable across all to classes, functions, and variables. Other programs can 

platforms on which the CMS runs so that users can choose have references to these classes, functions, and variables 

among appropriate platforms. However, the application resolved at run-time. A program may both import and export 

framework itself must interact with the native Operating references. That is, the program may use other shared 

System or Graphical User environment on which the frame- 60 libraries and may serve as a shared library for other clients, 

work executes. Such interaction must be transparent to the A schema may comprise a set of such programs. The present 

user. invention includes schemas for general-purpose geometric 

In certain cases, special support must be added to the modeling as well as schema for interfacing to industry 

application framework to take advantage of advanced capa- standard exchange formats such as ''MicroStation DGN", 

bilities of certain platforms. Wherever possible, the capa- 65 "AutoCad DWG", and "STEP". 

bilities of these advanced systems should be emulated on The schema programs model information relevant to a 

lesser platforms. predetermined domain. Such domains include engineering 
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domains and other domains. The "schemas" represented by 
the schema programs include multiple ''classes'*, each of 
which defines a type of component that may be placed in a 
model. "Objects" or "instances" are created or "instantiated" 
from each class, where each object is placed in the model 
and represents the occurrence of a component for a specific 
purpose in the model. Each class includes a specification of 
the data ("variables") held by each instance of the class, plus 
the program code ("methods") that may be employed to 
manipulate such variables. 

The objects in a model are stored in one or more reposi- 
tories or "stores". Related stores are logically grouped into 
a "project" which generally corresponds to a physical 
project (engineering or otherwise) in the real world. Projects 
are managed as a single unit by the CMS and are stored in 
a "project database", generally on a networked server, so 
that concurrent access can be granted to multiple users of the 
project. 

To initiate a user session, a user executes a query of the 
project database to extract a subset of the project (i.e. a 
number of related objects) from the project database into a 
local database. Since the format of the objects in the project 
database and in the local database is not necessarily the 
same, translation may be necessary. The extraction is con- 
sidered a long-term transaction to the project database such 
that during the user session no further interaction with the 
project database is required. If changes or additions are 
made to the extracted model objects during an editing 
session, such changes and additions may be posted to the 
project database at the end of the user session, at which time 
conflicts that have occurred due to changes by other users 
are resolved. 

Since objects in a project database are defined and inter- 
preted by the combination of instance data and class 
methods, instance data cannot be interpreted without the 
corresponding schema. Accordingly, to maintain the integ- 
rity of the project data, it must never be possible to encounter 
an instance without the corresponding schema. 

For this reason, the CMS of the present invention treats 
not just the geometry but also the programs that comprise a 
schema as components of the project database, as with the 
instance data. Accordingly, whenever an instance of a class 
is created in a project database, the schema of the created 
instance is also copied into the database. Thus, whenever 
instances of that class are encountered in future sessions, the 
schema is loaded into memory from the project database. 

A benefit of an object-based CMS is that information may 
be shared with other object-based programs by publishing 
appropriate interfaces. There are several standards proposed 
for the mechanism by which objects make requests and 
receive responses from interfaces of other objects. TWo such 
standards are the Cbmmon Object Request Broker Archi- 
tecture (CORBA) proposed by a vendor consortia including 
Hewlett-Packard Corporation, IBM Corporation, and others, 
and Component Object Model (COM) from Microsoft Cor- 
poration. 

SUMMARY OF TIIE INVENTION 

The present invention includes a computer system for 
modeling, where the computer system has a storage device, 
first and second platforms, a portable persistent model, and 
first and second platform-dependent computerized modeling 
systems (CMS). The first and second platforms are inter- 
faced to the storage device, and each platform provides 
system-dependent services. Hie first platform has a first type 
of operating system and a first type of computer hardware 
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including a first memory, and the second platform has a 
second type of operating system and a second type of 
computer hardware including a second memory. 
The portable persistent model resides in the storage 
5 device in a platform-independent format, and includes per- 
sistent component objects. The first platform-dependent 
CMS resides in the first memory of the first platform and the 
second platform-dependent CMS resides in the second 
memory of the second platform. Each CMS provides CMS 
10 services including retrieving the model from the storage 
device, manipulating the model, changing the model by 
adding and removing persistent objects, and persistently 
saving the model to the storage device. 

In the present mvention, each platform-dependent CMS 
includes a static kernel and a dynamic framework. The static 
kernel executes on the platform and interfaces to the oper- 
ating system and the computer hardware, and provides 
services necessary to load and execute CMS services and to 
interface to the platform services. The dynamic framework 
executes on the platform and interfaces to the kernel, pro- 
vides a platform-independent visual interface between the 
CMS and a CMS user, and employs the services of the 
kernel. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing summary, as well as the following detailed 
description of a preferred embodiment of the invention, will 
be better understood when read in conjunction with the 
30 appended drawings. For the purpose of illustrating the 
invention, there is shown in the drawings an embodiment 
which is presendy preferred. It should be understood, 
however, that the invention is not limited to the precise 
arrangements and insUiimenlalilies shown. In the drawings: 
35 FIG. 1 is a block diagram of the architecture of a CMS in 
accordance with a preferred embodiment of the present 
invention; 

FIG. 2 is a more detailed block diagram of the model, 
framework, and kernel of the CMS shown in FIG. 1: 

40 . . 

FIG. 3 is a block diagram showing elements included 
and/or accessed by the framework of FIGS. 1 and 2; 

FIG. 4 is a block diagram showing schemas included with 
the model of FIGS. 1 and 2; 
45 FIG. 5 is a block diagram showing key language features 
of the programming language of the present embodiment, 
including classes, interfaces, and templates; 

FIGS. 6 and 7 are block diagrams showing a class 
definition and an interface definition, respectively, in the 
50 preferred embodiment of the present invention; 

FIG. 8 is a block diagram showing the run-time interac- 
tion between dependent objects in the preferred embodiment 
of the present invention; 

FIG. 9 is a flow diagram showing the process of dynamic 
casting in the preferred embodiment of the present inven- 
tion; 

FIG. 10 is a block diagram showing a global table of 
method selectors and a dispatch table for a class derived 
from the global table in the preferred embodiment of the 
present invention; 

FIG. 11 is a block diagram showing a statically allocated 
object embedded within another object in the preferred 
embodiment of the present invention; 
65 FIG. 12 is a block diagram showing *dirty* and 'change' 
bits in object descriptors of dependent objects in the pre- 
ferred embodiment of the present invention; 
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FIG. 13 is a block diagram showing a virtual machine an optical drive in which the portable persistent model 16 is 

stack and a native code stack in the preferred embodiment of stored. In the preferred embodiment of the present invention, 

the present invention; the kernel 12 is written in the well-known "C" and "C++" 

HG. 14 is a block diagram showing a compiled program programming languages, is compiled using vendor-suppUed 

that can be run on multiple different platforms in the 5 took mto a native code appropnate to the ^ 

preferred embodiment of the present invention, each plat- fo iJ^ ^ ^ i specific for each of several pUtforn^ 

J. . . , ,o 1 u- The kernel 12 executes at fiill machme level speed and 

form having a platform-speafic virtual machme; ^ ^^^^^^^^^ ^^^^ ^^^^^^ ^^^^^ j^y^^ 

nG. 15 is a diagram showing a data value apportioned T^e kernel 12 provides services to the higher levels by 

according to a segmented specifier in the preferred embodi- exposing a function call-based application programmer 

ment of the present invention; interface ("API"). As should be understood, the API has 

FIG. 16 is a diagram showing a list of data values "native code" fimctioos that are accessed via direct calls 

apportioned according to a segmented specifier in the pre- from the next higher level software layer (i.e. the framework 

ferred embodiment of the present invention, where the 14). The addresses of the native code functions in the kernel 

apportioned data values are organized to be stored; 12 are resolved using Dynamic Link Specification (DLS) 

FIG. 17 is a flow diagram showing the validation process ^ ^^^^ provided with the kemel 12. Higher level layers can 

in the preferred embodiment of the present invention; presume that the kernel 12 will always be present to provide 

TTtr^ io • ui 1 J- I. • *u • * services, despite the fact that the kemel 12 is non-portable. 

FIG. 18 is a block diagram showmg the persistence i_ .jjuij- jj-*- i 

.... L ' r J- • * . * * The kemel 12 can be extended by loading additional 

binding mechanism for binding a persistent object to a , j. i • u • . j r^r o i. 

. . ^ . . ^, c J u J- * . - dynamic modules 23 with associated DLS files; however 

persistent store in the preferred embodiment of the present 20 J , , , . » . r *u c ^t. j i 

r ^ *^ higher levels must test for the presence of these modules 

mvention, , *j 

before using them. 

FIG. 19 is a block diagram showing a persistent object ^ 2, the kernel 12 includes a CMS virtual 

stored ,n a persistent store in the preferred embodiment of ^^^^^^ ^4, as will be described below, and an interface 26 

the present mvention, ^ ^^^^^^ graphical user interface ("GUI"). AdditionaUy, 

FIG. 20 is a more detaUed block diagram of the project the kemel 12 includes various support libraries 28 that are 

database and persistent stores shown in FIG. 1; necessary for nearly all CMS programs. These include 

FIG. 21 is a table showing the different states of a libraries for: file and resource I/O, configuration 

persistent object in the preferred embodiment of the present management, general vector and matrix algebra, memory 

invention; management and diagnostics, system event handling, macro 

FIG. 22 is a block diagram showing properties added to language interface, solids modeling, and graphics display, 

an object in the preferred embodiment of the present inven- among others. 

tion; The kernel 12 also includes an object^ersistence manager 

HG. 23 is a block diagram showing an implementation of ^® responsible for the allocation, references, and persistence 

the CMS of FIG. 1 that incorporates remote objects; 35 0^ a" o^J^^ts in the model 16. Whenever a new object is 

ITT/- ^yi uii^' u- t **■ f created, the object/persistence manager 30 creates an object 

FIG. 24 is a block diagram showmg an implementation of , . ' r i_- . » •« if j -l j i_ 1 » 

the CMS of no. 1 that aUows a Lr to And a specific '^f "P'°' the object. As wm be described be ow. aU 

component for a model from an external site; and 'f^^f^o^ to an object are through rts object descriptor. The 

object/persistence manager 30 can therefore manage ' object 

HGS. 25 and 26 are block diagrams showmg parse trees faulting" when objects are reloaded from disk, as will be 

developed by the compiler m the preferred embodunent of described below, as well as the synchronization and data 

the present mvention. manipulation required to e^ablish connections to objects on 

DETAILED DESCRIPnON OF PREFERRED remote computers^ 

EMBODIMENT firamework 14 provides a platform -independent 

45 visual interface between the CMS 10 and a CMS user. The 
Architecture framework 14 uses the services of the kernel 12 and incor- 
porates the logic necessary for employing those services to 
Referring to FIG. 1, the present invention includes a CMS address the CMS requirements described above. Although 
10 having an architeclure that can be viewed as several the framework 14 of the preferred embodiment of the 
dislincl layers including a static kernel 12,^^dynamic 50 present invention is primarily directed at engineering-type 
framework 14, and a portable persistent |^|h1 16 con- modeling, one skilled in the art will recognize that different 
stnicted from a set of schemas 50 (as seen^ FIG. 2) and frameworks could be developed using the same basic con- 
stored in one or more persistent stores^S of a project cepts to address related, tangential, or even different busi- 
database 17. Each layer serves a separate purpose and is ness problems with similar requirements for portability, 
constructed using different tools. Such architecture is 55 persistence, and data modeling. 

designed to accomplish the goals set forth above for Referring now to FIG. 3, the framework 14 is a visual 

efficiency, portability, and flexibility. interface that includes and/or accesses a system state object 

At the lowest level, the kemel 12 provides the services 32, system event responders 34, windows 36, viewports 38, 

necessary to load and execute the higher levels, as well as and graphics agents 40, among other things, llie framework 

the interface to the (necessarily system-dependent) services 60 14 is written in the object-oriented schema implementation 

of the imderlying platform 19. As seen, the platform 19 programming language referenced above for maximum 

includes the operating system and graphics system 20, and extensibility and maintainability. However, the framework 

computer hardware 22. As should be understood, the com- 14 is not necessarily portable, may have different behavior 

puter hardware 22 includes memory such as RAM memory on different platforms 19, and is not saved in the project 

in which the kernel 12, the framework 14, and at least a 65 database with the instance data for a project, 

portion of the portable persistent model 16 reside at run- The system state object 32 is the root object of the 

time, and at least one storage device such as a hard drive or framework 14 and is the known point for queries to deter- 
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mine the current state of the framework 14. As should be 
understood, the system state object 32 holds all of the system 
level state inform atioo that affects the behavior of the 
framework 14 and ensures that such information is always 
consistent and accurate. For example, the system state object 
32 holds a reference to the current project object, a list of the 
current system event responders 34, and a list of all open 
windows 36 on the screen, among other things. The system 
state object 32 is created as part of the initialization of the 
framework 14 itself. 

Each of the event responders 34 is designed for and 
executed in response to the occurrence of a specific event 
triggered by the user. Multiple responders 34 can watch for 
the same event, although typically only one will actually 
handle (process) the event. 

>^ndows 36 are employed as the interface between the 
user and the CMS 10 through which all interaction takes 
place. Typically, the window 36 is a rectangular region on 
the screen and provides a consistent visual interface on all 
platforms 19. Windows 36 are implemented using services 
provided by the graphics subsystem in the kernel 12. As 
should be understood a window 36 may be re-sized by the 
user or by method calls from a program, may be minimized 
or maximized, and may be visible or occluded depending on 
relations with other windows 36. 

V^ndows 36 are notified asynchronously when certain 
events occur, either as a result of an input from the user or 
as a byproduct of actions taken by other programs. Windows 
36 process certain of these events themselves and also 
maintain a list of responders 34 to further process the events 
that occur within their respective interiors. As is known, 
events are passed to each responder 34, in turn, until one of 
them returns a status indicating that the event has been 
handled. 

Viewports 38 are rectangular drawing regions into which 
programs display graphics output. The viewport 38 provides 
a graphics output interface that is accessible from within the 
framework 14, and that is independent of the window system 
and actual graphics device. Different kinds of viewports 38 
arc used to output to a window 36, to output directly to a 
non-window device for displaying graphics in other 
applications, and to output to a printer or plotter driver. In 
the first case, a viewport 38 is normally mapped to a specific 
subregion of a window 36, and more than one viewport 38 
can be displayed in a single window 36. In each case, only 
the implementation of the specific viewport 38 is changed. 
Preferably, each viewport 38 contains methods for drawing 
vectors, polylines, arcs, ellipses, B -Splines, text, and filled 
regions, among other things; an interface to a set of "active 
symbolog/* methods that manage color, line style, endcaps, 
line joins, line width, and fill parameters for the viewport 38. 

A graphics agent 40 provides the link between a model 
view 42 (i.e. a particular view of the model 16 or portion 
thereof as requested by the user) and an output device (not 
shown) such as is represented by a viewport 38. As is 
known, the graphics agent 40 provides a consistent sophis- 
ticated set of drawing primitives that can be used to reader 
any image. If a correspondingly sophisticated viewport 38 is 
used, primitives may be sent directly to the viewport 38 after 
transformation into viewport coordinates. If a less sophisti- 
cated viewport 38 is used, it is the responsibility of the 
graphics agent 40 to translate the primitives into the less 
sophisticated viewport primitives for display. Preferably, the 
graphics agent 40 holds an optimized version of a graphics 
pipeline for transformation from model to screen coordi- 
nates and vice versa. 
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A graphics agent 40 specialized for locate testing ('Mocate 
agent") (i.e. locating what object a user is pointing at, 
usually with a mouse) tests each primitive (i.e. each graphic 
display of an object in the model 16) for its location relative 

5 to a test point stored in the locate agent 40 and accumulates 
a list of "bits" within a specific range of the test point. From 
the list of hits, the locate agent 40 selects for a "likely hit" 
which is then made available from the locate agent 40. 

The process of creating or manipulating objects generally 
requires a series of actions that precipitate visual feedback, 
confirmations, and qualification of inputs. It is therefore 
necessary to maintain the "state information" while the user 
goes through the steps necessary to fiiUy indicate his inten- 
tions and refine incorrect or unintentional interpretations. To 
accomplish such a goal, and referring again to FIG. 2, the 
framework 14 of the CMS 10 of the present embodiment 
includes a command tool manager 44 that controls the 
process of manipulating the model 16 by way of a set of 
command tools (not shown). 

2Q As is known, each command tool has an expected set of 
inputs from which emanate predictable results. A specific 
command tool is only concerned with its set of expected 
input and can ignore all other inputs. In a typical CMS it is 
frequently desirable to suspend the implementation of one 

25 command so that another intermediate action can be taken. 
For example, while constructing physical objects based on 
existing objects, or when modifjdng an existing object, it 
may be desirable to visually zoom in on specific areas of 
interest in the model 16 for closer examination. However, 

3Q the input required by the zoom conunand (a data point 
indicating the region of interest) will likely conflict with the 
input expected by a construction/modification command. It 
is therefore necessary to start the implementation of the 
zoom command before the implementation of the 

35 construction/modification command has completed. 

For this reason, the CMS 10 of the present embodiment 
preferably stores an ordered list of command tools, each 
having a specified priority. Events are passed to each com- 
mand tool in order of priority until one returns a status 

40 indicating that the event has been handled. Command tools 
that control intermediate actions, such as the zoom 
command, are assigned a higher priority than construction/ 
modification tools. Other high-priority command tools "fil- 
ter** or modify the inputs to enforce user desired constraints 

45 such as locking coordinates to a scries of grid points in 
space, vertices, intersections, or other critical points of 
existing geometry; and setting distances to known values; 
among other things. 
As seen in FIG. 2, the framework 14 of the CMS 10 of the 

so present embodiment also includes a transaction manager 46 
that keeps track of all of the objects involved in a transaction 
and that saves a copy of the original conditions of such 
objects. Preferably, a transaction is defined as a series of 
related modifications or additions to objects in the model 16. 

55 A single transaction is typically associated with a single 
completed execution of a command tool. If, at a subsequent 
time, the user decides that be is not satisfied with the result 
of a transaction, he can request that the transaction manager 
46 "undo" the change. Also, if an error occurs during the 

60 course of processing a transaction, the transaction manager 
46 preferably can "unwind" the errant transaction so that the 
model 16 is unaffected thereby. 

The transaction manager 46 also handles transient objects 
displayed on the screen for visual feedback during the 

65 processing of a command tool. The transaction manager 46 
removes the transient objects from the screen when the 
command terminates. 
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The framework 14 of the CMS 10 of the present embodi- 
ment also includes a portable graphical user interface 
("PGUI") tool kit 48 that provides a consistent set of 
graphical user interface ("GUr*) tools independent of the 
underlying platform 19. A PGUI dialog window is based on 5 
a framework window 36 and is therefore system indepen- 
dent. PGUI dialog items are implemented entirely within the 
PGUI system and do not depend on windows or other dialog 
items operating system and graphics system 20. 
Accordingly, applications that use the dialog boxes and lO 
dialog items from the PGUI 48 do not require source code 
changes to operate on different platforms 19. 

The framework 14 also provides operating system level 
functionality independent of the underlying platform 19. 
Such functionality includes support for timers, exception 
handling, inter-process communication, shared libraries, 
directory searching, and file access. 
h As seen in FIG. 2, the portable persistent model 16 is 
Y constructed from one or more schemas 50 including a 
proj ect jschema , a modehng schem a, a drafting schema, 
compatibilit y sche mas, and other ^isSpline- or domain- 
specific schemas. As should be understood, a schema 50 is 
a s et of tools relevant to a particular fuactionali ty or domain 
or di^iplme^^jiexe. multi ple obj ects 52 dc fincd'S yloulti ple 
sch emas 50 can be combincd .intQ^single.model 16. As seen 
in FIG. 4, multiple schemas 50 may be stored in a single 
persistent store 18 and objects 52 defined by a schema 50 are 
stored in the persistent store 18 with the defining schema 50., 
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The present invention includes an object-oriented schema 
implementation programming language 53, as seen in FIG. 
5. The programming language 53 is designed to address 
several issues: 3S 

Unknown Objects 

The trend in the computer industry is toward small 
object-oriented program portions that can be used in many 
different programs. Although such program portions pro- 
vides considerable power for assembling a program from 
component software, such a program is fragile since the 
availability of all of the program portions is absolutely 
necessary. As should be evident, ensuring that all of the 
required program portions are available to the program is 
problematic. To resolve this issue, the programming Ian- 
guage 53 of the present embodiment requires that created 
program portions be stored with the databases the program 
portions create. The stored program portions are formatted 
in a manner known to the kernel 12 and are therefore 
executable on all platforms 19 for which a kernel 12 has 
been supplied. Thus, the software required to manipulate the 
data is always available and never unknown. 

Portability 

It is important that created program portions and data be 
movable from platform 19 lo platform 19 without compal- 
ibihty issues arising. That is, the program portions and data 
must operate in the same manner regardless of the particular 
configuration, system software, and hardware of the plat- 
form 19. The user must be able to copy the data and program gQ 
portions to another platform 19 and know that the data and 
program portions will move as a unit and work on the other 
platform 19. 

Persistent Relationships Among Objects 

lypically, when data is written to a file and read back, all 65 
of the numeric data and all of the strings are read back 
properly, but complex relationships among the data may be 



lost. If the complex relationships are maintained (i.e. made 
"persistent"), it is typically due to unusual effort by pro- 
grammers and the effort only solves the problem for a few 
relationships or for the object implementations developed by 
one group of prograouners. In the present embodiment, a 
persistence mechanism is provided to maintain such com- 
plex relationships across user sessions. 
Interoperability 

Program portions must be usable together even though the 
portions were developed independently. 
Encapsulation 

Program portions must be as isolated ("encapsulated") as 
possible while still providing functionality to other program 
portions. As should be understood, encapsulation means 
hiding as much information as possible and allowing other 
program portions to access information only when abso- 
lutely necessary and only programmatically, not by direct 
reference. Encapsulation is required to allow long term 
independent evolution of the program portions, and for 
isolating program errors as they arise. 

Object-oriented 

New objects 52 must be introducible into a CMS, and 
existing program portions must be able to employ the new 
objects 52 without any modification. Therefore, objects 52 
must be able to respond to standard actions required by 
existing program portions. 

Sp ecialization of Cbmpo nents 

A need often arises to create a new type of object 52 that 
is a specialized version of an existi ngjobkct 52. It can be 
assimied that any method that operateson the existing object 
52 can also operate on the new type of object 52, and that 

the new type of obiecl-5 2 also _has some adcj i ^ioaal char ac- 
terist ics not present in the exis ting object 52. 

Preferably, programs employed by the CMS 10 of the 
present embodiment are organized as shared libraries. 
Typically, one shared library implements a group of func- 
tionality or implements the behavior of a few classes in a 
schema 50. The ability to implement programs as shared 
libraries aids in encapsulation since everything but the 
public interface to a class can be limited to the small scope 
of a shared library. Shared libraries also support interoper- 
ability since different groups of programmers can provide 
shared libraries that operate together. Further, shared librar- 
ies help to solve the unknown objects issue discussed above 
since the programming language 53 of the present embodi- 
ment identifies the shared library that implements a class and 
copies the entire shared library to the data file that contains 
the persistent image of objects 52 instantiated from the class. . 

As shown in FIG. 5, the key language features of the 
programming language 53 of the present embodiment that 
support object-oriented programming are classes 54, inter- 
faces 56, and templates 58. 

As was discussed above, in terms of the run-time CMS 10 
of the present embodiment, a class 54 is part of a schema 50 
and defines an object 52 that may be instantiated from the 
class 54, where the instantiated object 54 can be placed in 
the model 16. In terms of the programming language 53 of 
the present embodiment that is compiled by a compiler 55 at 
compile-time to produce the schema 50, a class 54 defines 
member variables 60 (i.e. types of data) common to each 
object 52 and the methods 62 (i.e. functions) that operate on 
the member variables 60. The member variables 60 are 
employed by the CMS 10 to record the stale of an object 52 
instantiated from the class 54, and the methods 62 are 
employed by the CMS 10 to access and possibly modify the 
state of an object 52. Every object 52 is an instance of some 
class 54. 
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In the programming language 53, a "class declaration" 
defiDes a class 54 by listing the member variables 60 and 
methods 62 for the class 54. As seen in FIG. 6, the class 
declaration 64 for the class 54 declared the member vari- 
ables 60 and the names of the methods 62 of the class 54. At 
run-time, the class declaration 64 is embodied in a class 
object 52C for the class, as will be described below. 

The following example illustrates a class declaration 64 
for a simple '^Door" class in the programming language 53 
of the present embodiment: 

class Door Object 



14 



A programmer often wants to require that an object 52 
supports a set of methods 62, but does not want to restrict the 
object 52 to be a member of a specific class 54. It is much 
more powerful to allow the objects 52 to be a member of any 
5 of a variety of classes 54, provided that the classes 54 
support the set of methods 62. Accordingly, in the present 
invention, interfaces 56 are provided as a tool for expressing 
such a relationship. 

As seen in FIG. 7, the interface declaration 66 declares the 
10 names of methods 62 of the interface 56. An example of an 
interface declaration 66 is: 

interface Opening 



{ 55 
// Declare member variables 

double height, width; 
// Declare methods 

Door *setDimensi*ons (double height, double width); 

double getHeight ( ) const; 

double getWidth () const; 20 

}; 



As one skilled in the art will recognize, the above example 
is written in a programming language style. From the 
class declaration 64, the Door class has 'height' and 'width' 
member variables and methods 'setDimensions', 
'getHeight', and 'getWidth'. As should be understood, the 
source code for the methods 62 is typically not included in 
the class declaration 64, but instead is included elsewhere in 
the library having the class declaration 64. 

Qasses 54 may be derived from other classes 54, both 
logically and as they are expressed in the source code. For 
example, a "StormDoor" class may be derived from the 
Door class. As such the StormDoor class will have all of the 
properties of the Door class, plus properties that are specific 
to storm doors. In such a case, Door is a "base class" and 
StormDoor is a "derived class". Everything that is an 
attribute of Door is also an attribute of StormDoor. Common 
terms for the process of creating a new class 54 from an 
existing class 54 are specialization, derivation, and inherit- 
ance. Since StormDoor inherits all of the member variables 
60 and methods 62 from Door, there is no need to declare 
them in the StormDoor class declaration. An example of the 
class declaration 64 of StormDoor is: 

class StormDoor: Door 



{ 

int 

boolean 

int 

int 

); 



numberScreenPanels; 
glassPanelsAlIowed; 
gclNumbcrScrcens ( ); 
isGlassAllowed ( ); 



From the class declaration 64, the StormDoor class has 
'numberScreenPanels' and 'glassPanelsAlIowed' member 
variables in addition to the member variables of the Door 
class and methods 'getNumberScreens' and 'isGlassAl- 
lowed' in addition to the methods 62 of the Door class. The 
statement "class StormDoor: Door" signifies that Storm- 
Door derives from Door and that Door is a base class. 

An interface 56 provides a way to logically group meth- 
ods 62 independently of a class declaration 64. An interface 
56 represents a logical grouping of methods 62 for some 
purpose that may be performed by a number of classes 54, 
even classes 54 that are not otherwise related. 
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{ 

Opening 

double 

double 

}; 



*setDimettsions (double height, double width); 
getlfeight ( ) const; 
getWidth () const; 



From the interface declaration 66, the interface 'Opening' 
has the methods 'setDimensions', 'getHeight', and 'get- 
Width'. Any class 54 declared as supporting the interface 
Opening must implement all three of these methods 62 with 
the signatures defined in the interface declaration 66. At 
run-time, the interface declaration 66 is embodied in an 
interface object 52C for the interface 56, as will be described 
below. 

One interface 56 can extend or derive from another 
interface 56. For example, the interface "FramedOpening" 
adds to the interface evening: 

interface FramedOpening: Opening 



{ 

FramedOpening *setFrameDimensions 



40 



double 
double 

}: 



(double height, 
double width); 

gctFramcHeight ( ) const; 
getFrameWidth ( ) const: 



In the programming language 53 of the present 
embodiment, a class declaration 64 uses the keyword 
'implements' to mark the beginning of the list of interfaces 
56 that the class 54 supports. Accordingly, for Door to 
support Opening, the first line of the declaration of Door 
would be changed to: 

class Door: Object implements opening 

If a class declaration 64 for a class "Window" is: 



class Window: Object implements opening 



{ 

// Declare member variables 
double height, widUi; 
int numberPftnes; 

}; 



65 Then Wall could be declared as: 
class Wall: Object 
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{ 

tnt 

Opening 



numOpeniflg^; 
*oOpciimgB; 
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As one skilled in the art would appreciate, oOpcnings 
refers to a list including windows and doors, in this case, the 
use of the interface Opening has allowed the Wall class to 
refer to objects 52 that share the common characteristic that 
a Wall implementer cares about. 

A class 54 supports a first interface 56: (1) if the class 
declaration 64 for the class 54 names the first interface 56 in 
an 'implements* clause; (2) if the first interface 56 is a base 
interface to a second interface 56 and the class declaration 
64 for the class 54 names the second interface 56 in an 
'implements* clause; or (3) if a base class 54 of the class 54 
supports the first interface 56. An object 52 supports an 
interface 56 if the object 52 is an instance of a class 54 that 
supports the interface 56. 

At emplate 58 provides a flexible programming technique 
for declaring classes 54 and interfaces 56. A template 58 is 
a declaration of a "shell class*' or "shell interface'* with some 
of the type information parameterized (i.e. not filled in). The 
parameterized type information is then "filled in*' during 
compile -time according to other source code. For example, 
template 1' shown in FIG. 5 defines a shell class that has 
been filled in a first time to create * class Tl*, and a second 
time to create a 'class T2*. Accordingly, while *class Tl* and 
'class T2* arc structurally similar, the actual components 
represented by each class 54 may be quite different. 

Templates 58 are typically used for creating container, 
classes. Consider a class 54 that manages lists of objects 52. 
Without templates 58, a programmer must either create 
imp1empntafipnjL^^f 4b«4ist for every tvpe of object 52 that 
can appear inih sJjst, or must implement the list class 54 in 
a way that_by passes_t vpe safelv_Y6rifying algnpthmg^typi- 
cally present in^a compil er 55. Templates 58 allow a pro- 
grammer to implement a shell just once in the source code, 
and to let the compiler 55 make the template 58 work for allvib 
of the intended uses. 

The programming language 53 of the present embodiment 
provides encapsulation through classes 54 and access con- 
trol. All information representing the state of an object 52 is 
declared in the corresponding class declaration 64. A pro- 
grammer may establish in the class declaration 64 what 
classes 54 and functions are allowed to change different 
parts of the objects 52 instantiated from the class 54. 

A member variable 60 in a class declaration 64 may be 
declared to be "private", "protected", or "public*'. A private^ 
member variable 60 may only be accessed by methods 6 2 o'f 
the class 54 having the private member variable 60. A 
protected member variable 60 may only be accessed by 
methods 62 of the class 54 having the protected member 
variable 60 and by methods 62 of derived classes 54. A 
public member variable 60 may be accessed by any method 
62. By declaring all of the member variables 60 in a class 54 
to be private, the class 54 guarantees that all access to the 
state of an object 52 instantiated from the class 54 must be 
through the class methods 62. 

Interfaces 56 increase encapsulation. The implementer of 
a class 54 does not > even need to document the class 
declaration 64 to other developers if the class declaration 64 
implements a documented interface 56. All access to the 
member variables 60 of the "hidden" class 54 may be had 65 
through the methods 62 declared in the interface 56 and 
declared in the resulting interface declaration 66. 
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Preferably, a class declaration 64 may grant complete 
access rights to other classes 54 and methods 62 by using a 
"firiend** declaration. The fiiend declaration signifies that the 
specified class 54 or method 62 may access the member 
variables 60 of the class 54. 

As should be understood, access control can also be 
managed through the 'package* statement. The package 
statement is interpreted at compile-timc and declares that the 
source file being compiled is to be part of the program 
named in the package statement. All source files compiled 
with the same package statement have access to all of the 
member variables 60 of any class 52 implemented in that 
package. All of the object files generated from source files 
with the same package statement must be linked into the 
same program. Therefore, the package concept provides a 
tool for granting fiill public access to all code that is linked 
to the same program, but enforcing the standard access 
model to code that is not linked with the program. 

y^V\ Rim-time Representation of Object-Oriented Data 
Types 

Referring now to FIG, 8, every "resident** object 52 (i.e. 'I 
fully loaded into memory) is represented during run-time by / 
three groups of information: a handle 68, a n object desc rip- / 
torJO, and the object 52 itself as represented by instance / 
data 72 for such object 52. TheJiandl&.^8-is-a^iefefeace-to / 
the object.descriptoiJ70^The object descriptor 70 contains an | 
instance data reference 74 to the memory location of the j 
instance data 72 for the object 52, a class reference 76 to a | 
class object 52C associated with the class 54 from which the/ 
object 52 was instantiated, flags that indicate the state of am 
object 52, and a back-pointer reference 78 to a list ol 
back-pointers 80, where each back-pointer in the list Si 
points to another object 52 that has a reference to (i.e. h 
dependent on) the object 52. As should be understood, the 
instance data 72 of the object 52 contains the data declarec 
in the member variables 60 of the class declaration 64. 

Such object architecture allows an object 52 to have a 
reference to a "potential** object 52 (i.e. not loaded into 
memory) since such reference is to an object descriptor 70 
and not to a memory location. When the CMS 10 tries to 
access data from a potential object 52, the potential object 52 
is faulted in and made resident (i.e. loaded into memory) if 
necessary. Furthermore, by referring to an object descriptor 
70 rather than a memory location, an object 52 may be 
moved from one memory location to another without the 
need to adjust all references to the object 52. Instead, only 
the reference to the memory location in the object descriptor 
70 need be updated. 

'Vhc class object 52C represents the class 54 at run-time 
and embodies the class declaration 64 for the class 54 (as 
seen in FIG. 6). Accordingly, the class object 52C contains 
all the methods 62 invoked by all the objects 52 instantiated 
from that class 54. With each object 52 having a class 
reference 76 to a class object 52C, it is always possible to 
determine at run-time whether an object 52 belongs to a 
certain class 54. 

Since a class object 52C is an object 52, the class object 
52C must have a handle 68 and an object descriptor 70. The 
class object 52C contains information describing how the 
class 54 fits into any class hierarchy, a reference to the base 
class 54 for the class 54 (if one exists), the size of objects 52 
of the class 54, a dispatch table 84 (shown in FIG. 10) that 
indexes the methods 62 associated with the class 54, and a 
reference to a list of interfaces 56 implemented by the class 
54. 
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like any other object 52, a class object 52 C can be used 
to invoke naetbods 62. Accordingly, class objects 52C are 
employed to instantiate new objects 52 from the class 54. 
That is, class objects 52C are the factories that create new 
instances of objects 52. The methods 62 invoked by a class 
object 52C to instantiate an object 52 are referred to as class 
methods or factory methods. 

Further, the object descriptor 70 of a class object 52C 
must also point to a class object 52C ("meta class*') for the 
class 54. Just as a class object 52C contains all the methods 
62 invoked by all the objects 52 instantiated from that class 
54, so too must there be a meta class 54 that contains all the 
methods 62 invoked by the class object 52C. Ameta class 54 
contains the description of the associated class object 52C 
and a reference to a dispatch table 84 of methods 62 that can 
be invoked using the class object 52 C. 

Interfaces 56 are also represented by objects 52 at run- 
time. As should be understood, an interface object 521 (not 
shown) represents an interface 56 at run-time and embodies 
the interface declaration 66 for the interface 56 (as seen in 
FIG. 7). Accordingly, the interface object 521 refers to all the 
methods 62 declared in connection with the interface 56. An 
interface object 521 also contains the name of the object 521 
and a reference to the list of incorporated interfaces 56. 
Since interfaces 56 are not classes 54 and are not used to 
instantiate objects 52, interface objects 521 do not invoke 
methods 62 and no corresponding ''meta interface" is nec- 
essary. 

The run-time class objects 52C and interface objects 521 
allow programs to perform run-time type checking, or 
"dynamic casting". With dynamic casting, the CMS 10 can 
determine whether an object 52 is an instance of a specified 
class 54 or whether the object 52 is from a class 54 that 
supports a specified interface 56. 

In a dynamic cast, and referring now to FIG. 9, the CMS 
10 retrieves the class reference 76 from the object descriptor 
70 for the object 52 (S91) and compares that to the class 54 
specified in the query (S92). If they are the same, then the 
object 52 is an instance of the specified class 54. Otherwise, 
the base class reference 76 in the class object 52C for the 
object 52 is retrieved and examined to determine whether 
there is a base class 54 for the class 54 (S93), and if so, the 
base class 54 for the class 54 is retrieved (S94). The CMS 
10 then compares the base class 54 to the specified class 54 
(S95). If these match, then the object 52 is an instance of the 
specified class 54. llie comparisons continue until either a 
match is found or the root of the class hierarchy has been 
reached. If the process terminates without finding a match, 
then the object 52 is not an instance of the specified class 54, 
As one skilled in the art should now realize, the process is 
similar if the dynamic cast is to determine if the object 52 is 
from a class 54 that supports a specified interface 56. 

If experience shows that there are too many classes 54 or 
interfaces 56 for the aforementioned recursive search tech- 
nique to work efficiently, then various optimization tech- 
niques may be used. For example, the CMS kernel 12 could 
provide a unique selector index to each class object 52C and 
interface object 521 and attach a data structure to each of 
such objects 52C, 521, where each data strucmre is a list of 
all classes 54 and interfaces 56 supported. The data struc- 
tures would be organized to allow for quick access using the 
selector index, allowing the CMS kernel 12 to quickly 
examine a data structure to determine if an object 52 is a 
member of a certain class 54 or supports a specific interface 
56. The technique for this would be similar to the technique 
used for method dispatching (discussed below). 
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The CMS 10 of the present embodiment allows for 
polymorphic methods 62. As should be understood, a 
method 62 is polymorphic if the behavior of the method 62 
depends on the object 52 that invokes the method 62. In the 
5 CMS 10 of the present embodiment, "dynamic binding" is 
employed to implement polymorphic methods 62. 

Any language supporting polymorphic methods 62 
requires some sort of dynamic method dispatching. As 
should be understood, when a reference to an object 52 is 
10 employed to invoke a method 62, the system must use that 
reference to find the methods 62 associated with the object 
52, and then must use the method name itself to find the 
proper method implementation in a table of methods. 

In the CMS 10 of the present embodiment, every program 
is preferably provided with a list of all of the methods 62 that 
the program uses and all of the methods 62 that the program 
implements. When the program is loaded at run-time, the 
CMS 10 nms through the list trying to find each of the 
method names in a global table of methods 82, as seen in 
FIG. 10. If a method name is not foimd, such method 62 is 
added to the global table 82 and a system-wide index or 
selector value is associated with that name in the global table 
82 and is also stored in program memory. The selector for 
that method 62 is then placed at every reference to the 
method 62 in the run-time program. 

Since the method 62 has the same selector system-wide, 
and since every object descriptor 70 has a reference to a 
class structure having a dispatch table 84 for the class 54 of 
the object 52, the method 62 is selected from the dispatch 
table 84 in the CMS 10 of the present embodiment by 
constmcting the dispatch table 84 during run-time based on 
the global table 82. Since the dispatch table 84 is constructed 
at mn-time and not at compile-time, it is not necessary to 
re-compile all of the clients of a class 54 when a method 62 
^ is added to the class 54. 

Preferably, the dispatch table 84 for each class 54 includes 
the methods 62 of the interfaces 56 implemented by the class 
54. Accordingly, there is no need for a separate dispatch 
table 84 for each interface 56, as is required in "C++" and 
other object-oriented languages. With such an arrangement, 
an object 52 can invoke a method 62 even if the object 52 
only references an interface 56 that the class 54 of the object 
implements. 

45 If a dispatch table 84 was merely a copy of the global table 
82, the dispatch table 84 would be relatively large and would 
contain much unnecessary information about methods 62 the 
class 54 of the dispatch table 84 does not implement. 
Removing the un-implemented methods 62 from the dis- 

5Q patch table 84 would still leave a large structure that is 
relatively unpopulated. Accordingly, the dispatch table 84 of 
the CMS 10 of the present embodiment is based on a 
three-tiered sparse array, as shown in FIG. 10. 
As seen, the bottom tier may contain a plurality of lists, 

55 where each list has up to 16 entries and each list entry 
contains a method descriptor if the corresponding method 62 
from the global table 82 is implemented by the class 54 of 
the dispatch table 84. As should be understood, a bottom tier 
list exists only if necessary to contain a method descriptor. 

60 The middle tier may also contains a plurality of lists, 
where each list has up to 16 entries and each list entry points 
to a list in the bottom tier if such bottom tier list exists and 
contains a method descriptor. As with a bottom tier list, a 
middle tier list exists only if necessary to contain an entry 

65 that points to a bottom tier list. 

The top tier contains a single fist having up to 256 entries, 
where each entry points to a middle tier list if such middle 
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tier list exists and contains an entry that points to a bottom 
tier list. Presuming that a class 54 implements at least one 
method 62, the dispatch table 84 for the class would have 
one top tier list, at least one middle tier list, and at least one 
bottom .tier list. 

As should now be understood, for each method 62, the 
method selector from the global table 82 is employed to 
select all three tier entries for the method. For example, if the 
top tier list has 256 entries, each middle tier list has 16 
entries, and each bottom tier list has 16 entries, and if the 
selector is a 2-byte value, then the more significant byte is 
employed to select the entry in the top tier list, the more 
significant 4 bits of the less significant byte are employed to 
select the entry in the middle tier list pointed at by the 
selected entry in the top tier list, and the less significant 4 
bits of the less significant byte are employed to select the 
entry in the bottom tier list pointed at by the selected entry 
in the middle tier list, and the method descriptor for the 
method 62 is stored in such selected bottom tier list entry. Of 
course, one skilled in the art will now recognize that other 
variations on the three-tiered sparse array described above 
may be employed to produce a dispatch table 84 without 
departing from the spirit and scope of the present invention. 

With the three-tiered sparse array described, a dispatch 
table 84 may make references to up to 65,536 methods, 
although in almost all cases the dispatch table 84 would refer 
to far fewer methods 62. Moreover, since the array for the 
dispatch table 84 is sparse, memory management techniques 
can be employed to store the dispatch table 84 in a relatively 
small amount of space. 

For example, when constructing the dispatch table 84D 
for a derived class 54, as seen in FIG. 10, (and the dispatch 
table 84B for the base class 54 has already been 
constructed), it is preferable that the CMS 10 of the present 
embodiment first creates a default dispatch table 84D in 
which the top tier is newly constructed for the derived class 
54 but refers to the middle tiers that belong to the base class 
54 (B-2, e.g.). Therefore, the derived class 54 automatically 
inherits all of the methods 62 from the base class 54. 

After setting up the default table, the CMS 10 processes 
the lists of methods 62 that the derived class 54 implements. 
For each method 62, the selector from the global table 82 is 
employed to select the bottom tier list and entry for the 
method 62. If the bottom tier list for the entry akeady exists 
and is not shared with the base class 54 (D-13-2, e.g.), the 
selector is stored in such bottom tier list. If the lK)ttom tier 
list for the top tier entry akeady exists and is shared with the 
base class 54 (B-9-2, e.g.), then the CMS 10 aUocales the 
memory for a new bottom tier list in the dispatch table 84D 
for the derived class 54, copies the data from the existing 
shared bottom tier list to the newly allocated bottom tier list, 
and then stores the method descriptor in the newly allocated 
bottom tier list (D-9-2). Moreover, a reference to the newly 
copied bottom tier list is stored in the relevant entry of the 
relevant middle tier list for the derived class 54 (D-9). 
Before the reference can be stored, the relevant middle tier 
list may have to be copied from the base class 54 if not 
aheady present in the dispatch table 84D for the derived 
class 54. 

When a selector that has all three indices encoded is 
encountered, the process for selecting the method 62 corre- 
sponding to the selector using the three-tiered sparse array is 
as follows: 
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methodOescriptor - &unimplemeDtedMcthodDescriptor; 
mojorlndex - GET_MAJOR_INDEX (selector) ; 
^ if (majorlndex < pDi8palch'Dible->inaxMajor[iidex) 
{ 

pMiddleHer - pDispatch7Uile->pMiddIeTier -f maJorEndex; 
middlelndex - GET_MIDDLE_INDEX (selector) ; 
if (middleladex > pMiddleTlcr->maxMiddleIodex) 
{ 

10 pLowTier « pMiddleTiei middlelndex; 

Iwlndcx - GET_JLOW_JNDEX (selector) ; 
if (lowlndex < pLowner->inaxIndex) 
{ 

methodOescriptor «* 
&pLowller->inethod Descriptor, 
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Preferably, the programming language 53 of the present 
embodiment supports the concept of embedded object 
instance data. As should be understood, and as seen in FIG. 
11, the instance data 72 of an object 52 of one class 54 can 

25 contain the instance data 72 of an object 52S of an embedded 
class 54, or a pointer to the instance data 72 of the object 52S 
of the embedded class 54. The embedded instance data 72 is 
not actually an object 52 in that the embedded object 52S 
does not have an object descriptor 70. However, Uie pro- 

30 gramming language 53 must support using the instance data 
72 of the embedded object 52S to invoke methods 62. 
Therefore, whenever the embedded object 52S is employed 
to invoke a method 62, the CMS kernel 12 preferably creates 
a temporary object descriptor 70T having a reference to the 

35 instance data 72, a reference to the object 52 within which 
the object 52S is embedded, and a temporary object descrip- 
tor flag 86. 

Embedded instance data 72 associated with an embedded 
object 52S is considered to be part of the container object 52, 

40 and cannot exist separately. Accordingly, the persistent store 
18 within which the object 52 is stored does not know of the 
existence of the embedded instance data 72, and no other 
object 52 may contain a reference to such embedded 
instance data 72. As should be understood, while embedded 

45 objects 52S may be statically allocated in other objects 52, 
actual objects 52 can only be statically allocated as local or 
global variables, and cannot be statically allocated in other 
objects 52. 

I1ie performance benefits of statically allocated embed- 
so ded instance data 72 in embedded objects 52S should be 
understood when it is considered that objects 52 composed 
from multiple dynamically allocated objects 52 are more 
costly. More specifically, to compose an object 52 from other 
objects 52, it is typically necessary to dynamically albcate 
55 each of the component objects 52 and store their handles 68 
in the main object 52. Time is required to allocate the 
memory for each of the dynamically allocated objects 52, 
memory overhead is associated with every dynamically 
allocated object 52, programming effort is required to treat 
60 the main object 52 and its components as one object 52, and 
the persistence manager 30 (discussed below) must track 
each of the individual objects 52. Further, more time is 
needed to load and save multiple objects 52 than to load and 
save the same information as one main object 52 with 
65 embedded objects 52S. As seen in FIG. 11, then, it is 
preferable that the CMS 10 of the present embodiment 
supports statically allocated objects 52S embedded in other 
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objects 52 C'instance data structures"). Preferably, such object 52 is embedded. Preferably, the CMS 10 can call a 

embedding is defined in the instance data definition 100 of ''firee" routine that checks the allocation flag 86 in each 

a class 54. object descriptor 70. As should be understood, the free 

More preferably, when the compiler 55 of the CMS 10 routine acts to free up memory associated with dynamically 

encounters a declaration of a statically allocated embedded 5 allocated objects 52, if appropriate, and has no effect on 

object 52S, memory for the member variables 60 is statically allocated embedded objects 52S. 
allocated, but memory for an object descriptor 70 is not 

allocated. Instead, a temporary object descriptor 70T is Handling of TVpcs 

dynamically allocated at nin-time when the object 52 is used To allow a programmer to specify as much as possible 

to invoke a method 62. As should now be understood, such 10 about data types without creating imintended constraints, it 

an arrangement provides a tremendous savings if a relatively is preferable that the programming language 53 of the 

large number of objects 52 arc embedded. present embodiment supports composite types by having an 

Given a statically allocated embedded object 'myObject' *&&' operator in the context of type declarations. When 

and a method 'myMethod*, the method 62 can be invoked or used, the operator declares that an object 52 is a 

called using the syntax * my Object .myMelhod ()'. Since the 15 member of a certain class 54 and also that the object 52 

first parameter to myMelhod will be a handle 68 that points supports some additional methods 62. For example, given a 

to the object descriptor 70 for myObject, the CMS 10 must class *MyClass' and interfaces *interfacel* and 'interface2', 

generate a temporary object descriptor 70T as part of the a progranuner can specify that an object 52 is a member of 

call. The temporary object descriptor 70T must be retained MyClass and also supports both of the interfaces 56 by using 

until the end of the statement that invokes the method 62. If 20 the syntax: 
myMethod returns the handle 68 that was used to invoke it, 

then the following statement saves a pointer (i.e. a reference) MyClass && interfacel && interface2 ^oObject; 
to the temporary object descriptor 70T: 

In effect, an imnamed data type has been declared, and at 

MyClass *pMyObject»myObject.myMethod ( ); 25 some point in the future an operation will take advantage of 

the data type to operate on an object 52 that is instantiated 

However, attempts to use the returned handle 68 are invalid from class 'MyClass' and that supports the methods 62 in the 

as they may or may not work depending on whether the data type. In such a declaration, the first type may be either 

temporarily allocated memory has been reused. a class 54 or an interface 56. If the first declaration is not a 

To one skilled in the art, it might at first seem natural to 30 class, then class Object is assumed by the compiler. The 

declare a pointer to an object 52 and to assign the address of types following the first * &&' operator must all be interfaces 

a statically allocated embedded object 52S to the pointer. For 56. These may be interfaces 56 that were explicitly declared, 

example, or interfaces 56 that were created by combining interfaces 

56 with a 'Cypedef ' operator. For example, given interfaces 

MyClass *pMyObject=&myObject; 35 *interfacel% 'interface2', and 'interfaces', the following 

statements create composite types *combincdinterfaces' and 

However, the CMS 10 of the present embodiment does not 'moreCombinedJnterfaces', respectively: 
permit such a statement since MyClass * is a handle 68 that 

points to an object descriptor 70 for a MyClass object and typedef interfacel && interface2 combinedinterfaces; 

&myObject is a pointer to the instance data 72 of a MyQass 40 typedef interfaces && combinedinterfaces moreCombined- 

object. Put simply, MyClass * and & myObject are different Interfaces; 
data types. 

To overcome the aforementioned problem, the program- Preferably, the programming language 53 of the present 

ming language 53 of the present embodiment preferably embodiment implements the concept of narrowing of types, 

includes a keyword such as 'embedded' that allows a pro- 45 Type A is considered narrower than type B if the set of 

grammer to declare a pointer to the instance data 72 of an objects 52 that are type A is a subset of the set of objects 52 

object 52. As should be understood, 'embedded' is a type that are type B. Such relationship is determined partially by 

modifier, and must appear before a class name. To allow the class component and partially by the interface oompo- 

pMyObject to point to myObject, MyClass must be declared nent. Type A is narrower than type B if the class component 

as: 50 is narrower and the interface component is narrower. 

I1ie class component of type A is narrower than the class 

embedded MyClass *pMyObject-&myObject; component of type B if type A is either directly or indirectly 

derived from type B. Ignoring interfaces 56, if type A is 

As discussed above, an object descriptor 70 is allocated derived from type B then everything that is of type A must 

automatically whenever a statically allocated embedded 55 also be type B. Accordingly, if type A is narrower than type 

object 52S is used to invoke a method 62. Preferably, it is B, any operation that will work on type B will also woilc on 

also possible to generate a handle 68 and object descriptor type A (i.e. will accept any type broader than type A). The 

70 using an ' ALLOCArE.JlANDLE' operator. As should interface component of type A is narrower than the interface 

be understood, such operator operates on a statically alio- component of type B if every interface 56 supported by type 

cated embedded object 52S and remms a handle 68 that 60 A is also supported by type B. 

points to the object descriptor 70. Each object descriptor 70 Preferably, the programming language 53 of the present 

created in such a way must be explicitly freed using a embodiment also implements the concept of assigmnent 

*FREE_HANDLE' operator. compatibility. As should be understood, assignment com- 

To facilitate management of object descriptors 70, each patibility determines whether a value is allowed as an 

object descriptor 70 preferably contains an allocation flag 86 65 aigument to a function or method 62. Type A is assignment 

to indicate whether the object 52 is statically (1 in FIG. 11) compatible with type B if a value of type A can be assigned 

or dynamically (0 in FIG. U) allocated, and whether the to a value of type B. An operation expecting an input of type 
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B can accept an input of type A if type A is assignment As one skilled in the art would recognize, ''casting" is a 

compatible with type B. programming concept whereby an object 52 of type A is 

If the declarations of types A and B ^edfy some com- treated as if it were of type B so that the object 52 can be 

bination of interfaces 56 and classes 54, then a value of type operated on by an operation expecting type B. However, 

A can be assigned to a value of type B only if type A is 5 casting by its nature is intended to "fool" the compiler 55 

oartower than type B. That is, a value of type A can be during type checking at compile-time, and run-time errors 

assigned to type B only if the set of objects 52 satisfying type ^an result if the programmer is inattentive. Since anything 

A is a subset of the objects 52 satisfying type B; and a value ^e changed by a cast, it is far too easy for a programmer 

of type Acan be assigned to type B only if type A supports ^ ^^^^^ ^^^^ jj^^ 55 ^^^^^j ^^t^^^ 

every interface 56 required by type B, and the type B class Nevertheless, some casts are necessary, so it is preferable 

IS a base class of the type A class. .u . .u • 1 *^ c *u ; u j- 

As should be under^iod, the concepts of narrowing and programming language 53 of the present embodi- 

assignment compatibility add flexibiUti' to the prograniiing ^^PP°;^ ^ technique for casting tha solves these 

language 53 of the present embodiment. More importanUy, Problems. More preferably, the programming language 53 of 

such concepts increase the ability of the CMS 10 to perform P^^°^ embodiment supports the casting operators that 

type checking and other forms ofeiTor checking at compile- 15 have been introduced in the C++ programming language, 

time rather than at run-time. version 3.0: dynamic_cast, reinteipret_cast, const_cast. 

When a programmer creates a method 62 of a derived and static_cast. 

class 54 that overrides a method 62 of a base class 54, there The concept of dynamic casting during run-time was 

is often a need to change the declarations in the method 62 discussed above in terms of determining whether an object 

of the derived class 54 to narrow the return type (i.e. the type 20 52 is of a certain class 54. The syntax for a dynamic cast is: 
of a value provided by the method) so that a reference to a 

base class 54 becomes a reference to a derived class 54, or dynamic^cast <NewQass *> (expression) 
to make a similar change to a parameter type (i.e. the type 

of a value provided to the method). This Xypt of change is where 'NewQass' must be either a class or interface name, 

allowed for return types but not for parameter types. 25 possibly followed by an interface list. 

To understand why, consider what happens when a As should now be understood, dynamic casting can be 

method 62 of the derived class 54 is called in a context employed to navigate the class hierarchy and to safely test 

where the compiler 55 only knows that the object 52 is a whether an object 52 supports an interface 56, and can be 

member of the base class 54. Such a situation occurs employed both to narrow and broaden types. Preferably, the 

frequently in object-oriented languages, because a variable 30 type conversion that results from a dynamic cast is verified 

declared as a reference to a base class 54 can contain a at compile-time, to the extent possible, and the compiler 55 

reference to an object 52 that is a member of one of the generates code to verify the rest of the type conversion at 

derived classes 54. When the compiler 55 performs the type run-time. If the run-time tests all pass, then the dynamic cast 

checking on the method invocation, such compiler 55 can provides a reference to the casted object type. Otherwise, the 

only use the method declaration from the base class 54 even 35 dynamic cast returns a 0. 

though at run-time the method 62 in the derived class 54 will If, in a dynamic cast, an object 52 of a derived class 54 is 

be invoked. converted to an object 52 of a base class 54 ("up-cast") (i.e. 

As one skilled in the art should recognize, then, an illegal a broadening of type), then the compiler 55 can determine 
narrowing of the type occurs if an argument is a reference to that the conversion is valid and no run-time code is gener- 
the base type satisfying the requirements of the declaration 40 ated. However, if an object 52 of a base class 54 is converted 
in the base type, but the method 62 from the derived class to an object 52 of a derived class 54 ("down-cast") (i.e. a 
54 that is being invoked expects a reference to the derived narrowing of type), then the conversion must be checked at 
class 54, then that is an illegal narrowing of the type. No run-time and the compiler 55 generates the proper code for 
compiler 55 can detect the illegal narrowing in this method such run-time checking. Up-casts do not require any run- 
invocation, because the compiler 55 can only use the method 45 time checks since every object 52 is implicitly a member of 
declaration from the base class 54. In fact, the method 62 each base class 54 from which the class 54 of the object 
that is invoked may be coded after the invocation is com- derived. Up-casts are valid without a dynamic cast. Down- 
piled, casts always require dynamic casts and a run-time check. 

llie only way to avoid such an illegal narrowing is to Up-casting and down-casting to interfaces 56 is handled in 

prohibit changing the method declaration in the derived 50 a similar manner. 

class 54. llie problem is alleviated somewhat by employing Preferably, a dynamic cast may include types that were 

the convention that the first parameter to a method 62 is created from both interfaces 56 and classes 54. For example, 

always a pointer to the object 52 used to invoke the method the expression type may be 'BaseClass && Interfacell *' 

62. Accordingly, the type of the first parameter is known to and the taiget type may be *DerivedClass && Interfacel && 

be a pointer to an object 52 that is a member of the class 54 55 Interface2 In such an expression, the compiler 55 may 

where the method 62 was implemented, or a derived class 54 generate multiple run-time cast operators, one for each piece 

of that class 54. Such implicit narrowing of one parameter of information that such compiler 55 cannot verify at 

is preferably built into the CMS 10 of the present embodi- compile-time. 

ment. A dynamic cast cannot remove any type qualifiers. For 

To understand why narrowing a return type is allowed, 60 example, if the type of the expression is 'const BaseCass', 

consider that when a method 62 of the derived class 54 is the taiget type must also be a 'const' type. The const type 

called in a context where the compiler 55 only knows that qualifier is discussed below, 
the object 52 is a member of the base class 54, the method 

62 returns a reference to an object 52 of the derived class 54. Templates 

Where the method 62 is invoked, the compiler 55 expects a 65 The concept of a template 58 as a language feature was 

pointer to the base class 54. Such implicit broadening of type described above. As was discussed, templates 58 provide a 

is acceptable. mechanism for implementing container classes. A container 
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class is a class 54 that holds references to objects 52 of other 
classes 54. The container class provides for storage and 
some kind of ordered, fast access to the objects 52 contained 
within such container class. 

In the programming language 53 of the present 
embodiment, templates 58 are created by defining a param- 
eterized class (""shell class") and preceding the shell class 
with the keyword "template* followed by a list of types that 
are to be parameterized. To use the parameterized type in a 
class declaration 64, the class name is specified as in a 
normal declaration and is followed by a hst of type argu- 
ments. The compiler 55 of the present embodiment substi- 
tutes the arguments for the parameters and creates the 
executable code for the template 58 itself using the template 
constraint type. 

As seen in FIG. 5, templates 58 are preferably compiled 
prior to instantiation. Therefore, the compiler 55 must know 
what attributes of the argument type the template imple- 
mentation uses. Also, when the template 58 is instantiated 
the compiler 55 needs some mechanism to determine if all 
of the requirements have been met. Therefore, type argu- 
ment constraints must be expressed in a template declaration 
to let the compiler 55 check for consistency of the instan- 
tiation. Because the different instantiations of a template 58 
do not get different implementations, nothing in the template 
58 can depend on the size of the type parameter, and there 
are restrictions on assignment compatibility of parameters. 

More specifically, the layout of the shell class cannot 
depend on the size of the type parameter. Therefore, the shell 
class itself cannot contain any occurrences of the type 
parameter. As should be understood, if such a situation were 
allowed, the layout of the structure would be different 
depending on the type. Also, nothing in the implementation 
of a template 58 can depend on the size of a type argument. 
Therefore, using a 'sizeof* operator on the type parameter is 
not permitted. Also, performing pointer arithmetic on a 
pointer to a type parameter is not pennitted, and is in fact 
meaningless in the present context. 

Within the implementation of the template 58, for the 
puiposes of determining assignment compatibility, a tem- 
plate constraint is considered to be broader than but not 
equal to the parameter type. Consider the following two 
template declarations: 

template <class Param: Line> // 'first template' 
class BaseClass: Object 



{ 

Param *oParam; 

Param *save (IJnc *oInput) ; 

}; 



template <class Param: Lino // "second template' 
Param ^BaseClass::save (Line ^oLine) 



{ 

oParam « oline; // INVALID 

return pParam; 
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The assignment statement is invalid in the second template 
declaration even though 'Param' type is constrained to be at 
least a "Line\ If a program instantiates this class providing 
a type argument of a class that is derived from "Line' then 

5 such statement is incorrect. Therefore, the compiler 55 must 
generate an error because there is a chance that the statement 
may become incorrect depending on what type argument is 
provided during instantiation of a class 54 &om the template 
58. Conversely, "oLinesoParam* is allowed since every 

10 oParam must point to some Line. 

Template types can appear as type arguments to other 
templates 58 (i.e. can be nested). Given a template "Array', 
then, the following statement is valid: 

15 Array<Array<People»cmployees; 

A type parameter can also be used for a template argu- 
ment. For example: 

template <class savedType: String> class StringAvlTree: 
AvlTree <savedType> {, . . [member declarations] . . . }; 

In the above example, the template parameter is used as an 
argument to "AvlTree*. When "StringAvlTree' is 
instantiated, the type argument for "savedlVpe* is used every 
place StringAvlTree uses savediype, plus every place Avl- 
Tree uses its parameter type. 

Outside of the template 58, the parameterized type takes 
on the type of the parameter argument. For example, if a 
template 58 has a declaration: 

ParameterType ^getobject ( ); 

35 and the template class is instantiated with the template 
argument 'Name', then "Parameteriype' is treated as type 
Name for that instantiation. For example: 

ContainerType <Name> *oNameContainer; 
40 Name *oName; 

oName-oNameContainer->getObject ( ); 

is a valid statement. When "oName Container* is used to 
invoke "getObjecf, the type argument 'Name* is substituted 
45 for the type parameter, making getObject's return type 
"Name**. 

Two instantiations of template types generate the same 
class 54 if and only if the type arguments are the same. 
Consider the following declaration: 

50 

template <class savediype: Comparison> 

class AvlTree: Object {. . . [member declarations] . , . }; 

AvlTrcc <Name> ♦oFirst; 

AvlTree <Iotegcr> *oSecond; 

AvlTree <Name> ♦olliird; 

In this example, both "oFirsl* and 'oThird' point to instan- 
tiations of the same class 54, but "oSecond' does not. 
"AvlTree <Integer>' and 'AvlTree <Name>' arc different 
classes 54. 

Now consider how this concept extends to inheritance. 
Assuming the interface 'String' supports the interface 
'Comparison', declare the new class template as: 

65 

template <class savediype: String> class StringAvlTree: 
AvlTree <saved'iype> {. . . member declarations . . . }; 
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Given the declarations: 

AvITree <Namc> *oFirsl; 
SlringAvlTree <Name> *oFourlh; 

*oFourth* is considered narrower than *oFirst* because * AvI- 
Tree <Name>' is a base class 54 of * SlringAvlTree 
<Name>'. Therefore, it is possible to use a 'StringAvlTree 
<Namc>*' wherever a *AvlTrec <Name> *' is required. 
Dynamic casting oFourth to AvITree <Name> * is allowed 
and does not generate any run-lime type checking code. 

For the sake of assignment compatibility, an instantiated 
template 58 (i.e. a class 54) is treated like any other class 54, 
1\vo instantiated templates 58 are treated as the same type if 
and only if their type arguments are identical. 

An instantiated template 58 can be used as the target type 
in a dynamic cast by specifying the instantiated name as the 
target type. Using the declarations from the previous 
example, the following run-time dynamic cast can be used: 

dynamic_cast <StringAvlTree <Name> *> (o First) 

since the compiler 55 generates separate class objects 52C 
for both AvITree <Name> and StringAvlTree <Name>. 

Const Type Qualifier and Persistence 

C-derived languages support the concept of a "const" type 
qualifier, whereby data cannot be changed when modified 
with a const. Given a declaration: 

const Door *oDoor; 

'oDoor' cannot be used to modify the contents of the object 
'Door*. 

A class method 62 can be explicitly declared const by 
adding const after the method arguments. For example, 

inl getSize ( ) const; 

Every method 62 has an implicit parameter that is a pointer 
to the object 52 used to invoke the method 62. If a method 
62 is non-const, the implicit declaration is: 

ClassName *this; 

If the method 62 is const, then the implicit declaration is: 
const QassName *this; 

A const method 62 can be invoked using either a const or 
Don-oonst object 52. A non-const object 52 can only invoke 
a non-const method 62. 

Because managing const is difficult for programmers, it is 
preferable that the programming language 53 of the present 
embodiment supports the *const_cast' operator. As should 
be understood, const^cast provides the ability to "cast 
away" const from an object 52, but does not allow for 
changing the type in any other way. The syntax of a 
const_cast is: 

const^cast <new type> (expression); 

The new type must be identical to the type of the expression, 
with the exception that some of the const qualifiers may be 
removed. Const_cast must be restricted to objects 52, for 
reasons discussed below. 

If a const object 52 is used to retrieve a reference to other 
data, it is preferable that the programming language 53 of 
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the present embodiment propagates the const property to the 
other data. More preferably, the programming language 53 
considers such other data to be part of the referring object 52 
(i.e. propagates the const property). As is discussed below, 

5 such an interpretation is necessary for object management, 
including management of transactions and model persis- 
tence. If a const method 62 could modify anything the const 
object 52 refers to, then programs could easily modify data 
and bypass the persistence manager 30 of the CMS 10 

10 (discussed below) . That is, it would be possible to make 
changes in memory that would not be saved to a persistent 
store 18. 

Preferably, whenever the compiler 55 detects that some 
source code will cause an object 52 to be changed, the 

15 compiler 55 generates code to notify the CMS object/ 
persistence manager 30. During run-time, the notified object 
manager 30 then sets a "dirty bit" 88 (as seen in FIG. 12) in 
the object descriptor for the object 52 (i.e. marks the object 
dirty) to record that the object 52 is changed in the current 

20 session, and also sets a "change bit" 102 (also seen in FIG. 
12) in the object descriptor for the object 52 (i.e. the object 
is marked changed) to record that the object 52 was changed 
in the current transaction. Also preferably, whenever the 
compiler 55 detects source code that prevents such compiler 

25 55 from detecting whether an object 52 is to be changed, the 
dirty bit 88 and the change bit 102 are also set. In such a 
manner, the persistence manager 30 is informed that the 
object 52 must be newly saved to the appropriate persistent 
store 18, and the transaction manager 46 is notified that the 

30 object 52 must be included in the end-of-transaction pro- 
cessing (to be discussed below). 

An object is preferably also marked dirty if a value of a 
member variable 60 is retrieved and that member variable 60 
contains a pointer that is not a pointer to another object 52. 

35 As mentioned above, non-object memory that an object 52 
points to is treated as if part of the object 52. 

Preferably, the object/persistence manager 30 of the ker- 
nel 12 is notified when an object 52 has been changed. The 
object manager 30 then determines whether the changed 

40 object 52 is actually a statically allocated embedded object 
52S embedded within an embedding object 52. If so, the 
embedding object 52 is located by way of an embedding 
object reference (not shown) in the temporary object 
descriptor 70T for the statically allocated embedded object 

45 52S, and the embedding object 52 is marked dirty. 

The logic for deciding when the compiler 55 should 
produce change-notification instructions relies on compo- 
nents that: track whether a parsed expression refers to 
instance data 72 accessed through the instance data refer- 
so ence 74 of an object descriptor 70; decide whether the right 
hand side (RHS) of an assignment or an equivalent triggers 
any right-hand rules for emitting a change-notification 
instruction; and decide whether the left hand side (LHS) of 
an assignment triggers any left-hand rules for emittlog a 

SS change notification. As may be understood, for purposes of 
this description, an expression is considered a RHS if such 
expression actually is the RHS of an assignment, is used to 
compute the value in a return statement, or is used as a 
function argument. 

60 More specifically, the compiler 55 includes a parser (not 
shown) which must create a node in a parse tree for every 
component of the grammar recognized in parsing an expres- 
sion. As seen in FIGS. 25 and 26, when the parser applies a 
* . ' or * ->' operator to a node that refers to an object descriptor 

65 70, and the RHS of the operator is a data member, then the 
parser must create a first node which is either a GET_ 
INSTANCE_DATA node or a GET_CONST_ 
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INSTANCE_DATA node. The GET__INSTANCE_DArA computed. The compiler 55 then generates a DEREFER- 

oode tells the compiler's code generator that the instructions ENCE operator to use the data at the address determined by 

emitted for this node must retrieve the instance data refer- the left subtree of the DEREFERENCE node. The logic for 

ence 74 and also must invoke the run-time change notifica- propagation when creating a PLUS node is included in the 

tion logic. The GET_CONST_JNSTANCE_DArA node 5 discussion of the *+* operator, below. The logic for propa- 

tells the code generator that the instructions emitted for this gation when creating the DEREFERENCE node is included 

node must retrieve the instance data reference 74 but should in the discussion of the unary operator, below, 

not invoke the run-time change notification logic. The flags are always set to zero for the function call 

At the time the parser creates the first node (node 251 in operator. If change notification is required for the value 

FIG. 25, node 261 in FIG. 26), it does not have sufficient lo returned from a function, then that change notification must 

information to decide which type of node to generate. It occur in the function itself, not in the expression that calls 

cannot know how the data will be used imtil the expression the function. 

has been completely parsed, so it must use one of the node When a or *->* member reference operator is used to 

types as a default and fix up the first node as necessary when invoke a method, the flags are always set to zero. This is just 

the expression has been completely parsed. Preferably, the 15 a function caU. If the or *->* operator is used to access a 

compUer 55 generates a GET_CONST__INSTANCE_ member variable, then the behavior depends on both the left 

DATA node under the assumption that data members will be and right sides of the or 'operator. The left side is 

read more frequently than written and therefore defaulting to processed first, so processing the left side sets the flag values 

GET_CONST_INSTANCE_DATA will minimize the but processing the right side may clear those values. If the 

number of times it is necessary to fix up the first node. 20 left side is a pointer to an object 52, then the compiler 55 

When the compiler creates a first node which is either a creates a GET_CONST__INSTANCE_DArA node and 

GET_INSTANCE_J)ATA node or a GET_CONST_ sets both flags to 1. If the left side is a pointer to something 

INSTANCE__DArA node, it also sets 2 flags in such first other than an object 52, then the compiler 55 propagates the 

node. The first flag signifies that the current parse tree flags from the left side. Then, if the member ^ecifier on the 

retrieves an instance data pointer. The second flag signifies 25 right side of the operator specifies a volatile member 

that change notification may be required. As the parser (discussed below), the compiler 55 clears the change noti- 

continues parsing the expression, it propagates the values of fication flag of the new node. 

these flags to the parent nodes. When an expression is used The prefix and postfix operators and ' — 'all propa- 

as the RHS or LHS of an assignment, the compiler 55 uses gate the flags. For a casting operator, the result cannot be an 

the first and second flags as an aid in deciding if the parse 30 lvalue, llierefore, the result is propagated only if the new 

tree contains a GET_CONST_INSTANCE_DArA node type is a pointer to a non-object. The pointer to a non-object 

that must be changed to a GET_INSTANCE_DATAnode. is propagated because the data it points to is considered to 

To understand how the first and second flags are be embedded in the object 52 that contains the data, 

propagated, it is necessary to consider each type of parse tree However, if the pointer is to an object descriptor 70, then the 

oode that the compiler can generate. As one skilled in the art 35 object 52 may or may not be embedded. In either case, that 

will recognize, these node types correspond to the standard can be determined at run-time by examining the object 

rules of grammar for a C-derived language. Examples of descriptor 70. Both flags are propagated for both the unary 

such parse trees are shown in FIGS. 25 and 26. Using the *** and *&* operators. 

node types of the compiler 55 of the present embodiment is Most binary arithmetic operators cannot be used to gen- 

a means to illustrate the technique, but the technique can 40 erate lvalues or expressions of type pointer. Therefore, for 

easily be applied to other grammars and implementations, most of these the flags are set to zero. The exceptions are 

No changes can occur and therefore no change propaga- and The '+*, operand can be used to add a pointer 

tion is required if an operator cannot produce an lvalue and expression with a non-pointer expression. In this case, the 

also cannot produce a result that is a pointer type. Therefore, flags are propagated from the subtree that is of type pointer, 

the first and second flags are set to zero for all operations that 45 Otherwise, the values for a new *+* node are always set to 

only produce non-pointer rvalues. One skilled in the art will zero. Likewise, the operator can subtract a non-pointer 

recognize that the unary operators 'sizeof, and and from a pointer. In this case, the flags are propagated from the 

the binary operators 7*, *%% '»', '«', *<*, subtree that is of type pointer. Otherwise, the values for a 

*>=', '==', 'I*, *||*, 7b*, *— *«B*, *»-*, new node are always set to zero. 

*&»*, and '1=' all produce rvalues that cannot be pointer 50 For the assignment operator and the modify operators, 

types. 'ITierefore, for nodes corresponding to these operators, the data type and location of the data can be determined by 

the flagis are always set to zero. inspecting the left subtree. Therefore, the flags are propa- 

Since identifiers, constants, and strings do not have sub- gated from the left side. For the comma operator, the value 
trees and therefore have nothing to propagate, the flags are is determined by the right subtree. For example, in the 
always zero for associated nodes. For an expression 55 expression 'varl-fiinc ( ), var2', the return value from *func 
enclosed in parentheses, the compiler creates a parse tree by ( )* is not used. The generated code will call func, and then 
compiling the expression enclosed in the parentheses, but will assign the value of var2 to varl. Since only the right- 
does not add a new node for the parentheses. Therefore, most value is used, the flags are propagated from the 
there is nothing to propagate or to change. Propagation must right-most expression. 

be considered carefully for other operators including array 60 For the *V operator, the value may be supplied by either 

indexing, function calls, ' and *->* member reference, * ++* the left side or the right side of the required subsequent colon 

and * — the unary operators '++', ' — casting, * operator. Therefore, the propagated flag values are computed 

*+', and the additive operators *+' and the assign- by ORing together the corresponding values of the left and 

ment operators % and and the comma operator. right subtrees of the colon operator. 

For array indexing, the compiler 55 first creates a PLUS 65 The compiler 55 uses the node flags in its logic for 

node where the left subtree determines how the base address processing the LHS of an expression, the RHS of an 

is computed and the right side determines how the index is e}q>ression, the expression in a return statement, or an 
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expression used to compute an argument in a function call spirit and scope of the present invention. For example, 

or method invocation. A parse tree contains a GET_ multiple change-notification statements may be combined 

CONSTJNSTANCE^ATA node that is a candidate to be into one. If a change-notification instruction is emitted 

changed to a GET_JNSTANCE_JDArA if and only if the because a pointer to object data is assigned to a pointer but 

root node change-notification flag is set. In this case, the 5 analysis of the rest of the code block determines that such 

compiler 55 uses either an lvalue algorithm or rvalue algo- pointer is not used to change such data, then the change- 

rithm to determine if the node must be changed. The lvalue notification instruction can be eliminated, 

algorithm is used if the tree is the left side of an assignment In the CMS 10 of the present embodiment, methods 62 

statement (as is the case in FIG. 25), The rvalue algorithm may be implemented in programming languages other than 

is used if the tree is the right side of an assignment statement lo the programming language 53 of the present embodiment, 

(as is the case in FIG. 26), computes the value of a function For example, native code functions (platform-provided 

argument, or computes a return value. functions) may be invoked as methods 62. The programming 

If the change-notification flag is set (flag 252 in FIG. 25), language 53 of the present embodiment can not detect if an 

the lvalue logic always changes the GET_CONST__ object 52 is changed by the native code function. 

INSTANCE_J) ATA node. The lvalue algorithm used is: 15 Accordingly, whenever an object 52 is used to invoke a 

1. if the node's change-notification flag is not set, return. non-const native code function, the CMS run-time code 
Processing of the current subtree is complete. notifies the object manager 30 that the object 52 has changed 

2. if the node is a unary GET.^\DDRESS_OF, under the assumption that the object 52 will be changed by 
ACCESS_MEMBER_OF, DEREFERENCE, CAST, ^^^^ native code function. 

PLUS, or MINUS, apply the algorithm to the chUd ^° Without the restnction that consi_cast only works for 

subtree. objects 52, as discussed above, it would be possible to take 

3. if the node is a GET_INSTANCE_DArA or GET_ ^ P°"^*®f ^ * component of an object 52 and then to 
CONSr_INSTANCE_DArA, change the node to cast away such ooKt usmg that pomtcr. As s^^^^ 
GET_INSTANCE_DA1A and remra. Processing of ^X*^?^' P f!^^^ °^J^^ in such a 
the current subtree is complete. situation wiAout the object manager 30 bemg notified. 

A etu A W r-rxjr^KT nrTic x*iktito a Objects 52 may have member vanables 60 that are 

4. If the node ^ bmaiy COLON, PLUS MINUS or CAST {^^^^ ^^^^^ ^^^^ ^ 

no ca ion iary information that may be used in optimizing a search or 

5. if the node is QUESTION, apply the algorithm to the 30 display, but do not represent part of the state of an object 52. 
n^t subtree. The root of such subtree is the COLON preferably, the CMS 10 of the present embodiment can 
_ ^' modify such "volatile" fields without the object 52 being 

6. if the node is a COMMA, apply the algorithm to the marked dirty. To support such modification, it is preferable 
right subtree. that the programming language 53 of the present embodi- 

7. otherwise, return. 35 ment supports the use of a 'volatile* keyword to indicate that 
The processing of the current subtree is then complete. a member variable 60 is exempt from const restrictions. 

The rvalue logic is essentially the same, except that the Preferably, a volatile member variable 60 can be modified 
GET_CONST_INSTANCE_DATA node is changed only even if the object 52 is const, and a const method 62 can 
if the expression provides a pointer to data making it modify volatile member variables 60, but no others, 
possible to change the data without the change notification 40 d x* \r 1 k4 
occurring. Therefore, the rvalue logic only changes the node Run-lune \rirtual Machme 
if the data type of the expression is "pointer-to-nonconst". -As should be understood, the programming language 53 
Furthermore, the node is not changed if the expression is of the present embodiment is employed to write source code, 
"pointer-to-object-descriptor", since the object descriptor 70 Preferably, the source code is compiled into run-time code 
can be used to perform the change notification wherever the 45 ^^^^ be executed on any platform 19 having an appro- 
result of such expression is used to change the object 52. priately configured run-time virtual machine 24 with an 

In the parse tree shown in FIG. 25, the parser prelimi- interpreter or translator (not shown). As is known, a virtual 

narily sets node 251 to GET__CONST_INSTANCE_ machine interpreter interprets each mn-time instruction each 

DAIA, and such node 251 is subsequently changed to linic the instruction is executed, while a virtual machine 

GET_INSTANCE_DAIA since the change notification 50 translator translates a group of run-time instructions into 

flag 252 and the use-instance -data flag are set. Note that if native machine code instmctions. Accordingly, translated 

* index' was a volatile member (discussed below), the change insUnctions need not be re-interpreted each time the instruc- 

notification flag 252 would be reset to zero. In the parse tree ^i^^s ^re to be executed. Instead, translated instmctions are 

shown in FIG. 26, the parser detects at assignment that the retained for re-execution by simply branching to such trans- 

RHS has the change notification flag and the use-instance- 55 ^^^^^ instmctions. The following description of the virtual 

data flag set, and also detects that the data type is a pointer. machine 24 applies regardless of whether the virtual 

Since the pointed-to data is treated as if part of the object 52, machine 24 has an interpreter or translator, 

and since the location the pointer is assigned to is a pointer Many prior art virtual machines employ some variation of 

to non-const data, the parser must generate instructions to a stack-based architecture, where machine instructions 

invoke the change notification. Accordingly, node 252 is 60 "push" operands onto the top of the stack, operate on 

changed from GET_CONST_INSTANCE_DATA to operands that are on the top of the stack, store results on the 

GET_JNSTANCE_J)ATA. lop of the stack, and "pop" operands off of the top of the 

Although the present discussion examines the process the stack. With such a stack-based architecture code size is small 

compiler 55 uses when processing just one statement, one since many instructions implicitly operate on the top of the 

skilled in the art will recognize that standard optimization 65 stack and therefore need not explicitly specify an operand, 

techniques can be applied to reduce the number of change However, and as should be evident to one skilled in the 

notifications that are generated without departing from the art, the sUck-based architecUire is inefiScient in that oper- 
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ands are pushed and popped excessively to compensate for 
the faa that there is no way to directly address the operands. 
Such excessive movement is particularly inefficient in a 
virtual machine. 

To achieve efiBciency in a virtual machine, the instructions 
executed by the machine must be powerful enough that very 
few are required to perform a task, but simple enough that 
run-time interpretation or translation overhead is minimized. 
A register-based architecture allows for a reduction in the 
number of instructions required to implement a function, but 
is problematic in that the registers must be saved every time 
a function is called, and restored when the function returns. 
Moreover, since the number of registers in such architecture 
is limited, costly time is often expended shuffling interme- 
diate results of a calculation between registers and tempo- 
rary locations. 

Preferably, and as seen in FIG. 13, the virtual machine 24 
of the present embodiment solves the aforementioned prob- 
lems by employing a hybrid architecture that implements 
registers 90 as locations in a virtual machine stack 92, where 
the stack locations are pre-allocated at compile-time. 
Accordingly, rather than performiiig a simple add operation 
by pushing first and second operands on the top of the virtual 
machine stack 92, adding the two operands from the top of 
the stack 92, and leaving the result at the top of the stack 92, 
the virtual machine 24 of the present embodiment moves the 
first and second operands to specified locations in the virtual 
machine stack 92 and then adds the operands and stores the 
result in a specified stack location. 

Such an architecture is particularly advantageous when a 
function is called because the registers 90 are saved auto- 
matically merely by advancing the top-of-stack pointer. 
Therefore, there are no performance considerations for sav- 
ing the registers 90. Also, shuflfling is not necessary because 
the number of registers 90 is plentiful, and the results of 
previous operations may be re-used without moving the 
data. 

More significantly, the hybrid architecture allows the 
programming language 53 of the present embodiment to 
employ register variables, and the compiler 55 is able to 
allocate automatic variables and function arguments as 
register variables. Since the virtual machine 24 operates 
directly on registers 90, the machine can operate directly on 
automatic variables and function arguments, eliminating the 
need to copy the contents of a register variable to a work 
location. 

As was discussed above, the CMS 10 of the present 
embodiment can call native code functions that are in 
dynamic link libraries ("DLLs") and functions that are in 
standard system libraries. Preferably, the virtual machine 24 
invokes native code functions by employing an assembly 
language function that copies the function arguments from 
the virtual machine slack 92 to a native code stack 94, as 
seen in FIG. 13, and then dispatches the function. 

Preferably, every programming language function call 
instruction executed at run-time includes a description of the 
arguments that were pushed into the virtual machine stack 
92 for the function call. When a programming language 
function calls another programming language function, such 
description is not used. Nevertheless, every function call 
gets the description in case it is not known at compile-time 
whether the function is a native code function or a program- 
ming language function. 

The run-time call description is generated by the virtual 
machine 24 from a compiler-generated encoding string that 
describes the call arguments by distinguishing among 
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pointer-to-data, pointer-to-void, and pointer-to-fiinction 
arguments. Such encoding conveys enough information that 
the mn-time virtual machine 24 can determine on any 
platform 19 how to move the arguments from the virtual 
5 machine stack 92 to the native code stack 94. 

When a CMS program is loaded, it is preferable that the 
CMS kernel 12 convert the call encoding strings in the 
program to a format that can be used more efSciently by the 
assembly function that copies the arguments. Although the 
^0 format is the same for all platforms 19 currendy presently in 
use, future platforms 19 may necessitate format changes. 

Preferably, the CMS kernel 12 of the present embodiment 
maintains a hash table of all call encoding strings in use in 
the system. Accordingly, after a few CMS programs have 
been loaded, the CMS kernel 12 rarely has to generate the 
run-time call description but instead can use the hash table 
to find an appropriate already -generated call description. 

Preferably, the format of the run-time call description is: 

20 



typedef struct panmDescr 

ULong packtype; 
struct 

{ 

unsigned nwords : 8; 
unsigned copyOkay : 1; 

} f^&\ 
] PftramDescr; 

30 

The packtype field contains a compact description of the 
calling sequence. Each argument is represented by a 2 bit 
field in packtype. *00' as a packtype field means there are no 
more arguments. *10* means that the argument is a 4 bit 

35 quantity. '11' means that the argument is a double precision 
floating point value. The two most significant bits describe 
the return type of the function using the same encoding. 

The nWords field tells how much the native code stack 94 
has to be advanced to accommodate the arguments. The 

40 copyOkay flag indicates whether the arguments can just be 
copied as a group directly from the virtual machine stack 92 
to the native code stack 94. Preferably, the virtual machine 
24 always pushes arguments onto the native code stack 94 
the same way. More preferably, all 4-byte types are 4-byte 

45 aligned (start on the beginning of a 4-byte memory block) 
and all 8-byte types are 8-byte aligned. As should be 
understood, such an arrangement is employed by native 
code for some but not all platforms 19. When the virtual 
machine 24 generates a run-time call description, it is 

50 preferable that the arrangement for the arguments on the 
virtual machine stack 92 be the same for both virtual 
machine code and native code. If so, then copyOkay is set 
to 1 and nwords is set to a count of 4-byte words to copy. 
Otherwise, copyOkay is set to 0. 

55 When calling a virtual machine function from native 
code, the function arguments must be copied from the native 
code stack 94 to the virtual machine stack 92. To decide how 
to do that, the native code employs a parameter descriptor 
associated with the virtual machine function. More 

60 particularly, it is preferable that each virtual machine func- 
tion have a function header that contains a reference to a 
parameter descriptor for the function, where the parameter 
descriptor contains the information necessary to set up the 
virtual machine stack 92 for the called function. 

65 Preferably, the virtual machine 24 of the present embodi- 
ment can decide at run-time whether a particular function is 
a virtual machine function or a native code function. 
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Accordingly, and as should be understood, a program need to run on any supported platform 19. Specifically, such 

not be concerned with whether such program is calling into additional information includes a complete description of all 

native code or virtual machine code. Preferably, the first 4 of the data types used by the program 96, and descriptions 

bytes ofcvery virtual machine function are '00 00 00 00 H', oi all variables used by the program 96. The variable 

and the virtual machine 24 determines whether a called 5 descriptions arc required so that the layout of variables can 

function is a virtual machine function based on such infor- changed across platforms 19, ensuring that both the 

mation. Of course, one skiUed in the art wiU recognize that ^^V®^^ variables and their data sizes are correct, 

other differentiating conventions may be employed without f^^^r^ such additional information includes relocation 

departing from the spirit and scope of the present embodi- f"?^ ? ^"^^^ °f "^^^^^ 

jjj^jj^ o r r r affectcd by the mformation descnbed m the type system or 

list of variables 

Preferably, the virtual machine 24 of the present embodi- . 7 TT J^' . . . . , . . , 

ment implements instructions that support object manage- ^ ^ f '"'^'^^ ''PJ^f". °^ 1 

ment in the CMS 10. Such instructions include first instruc- P"*'*" additional in&rmaUon that a UachUonal 

....... in u -. . program does not require. In fact, sudi additional infonna- 

Uons to notify the object manager 30 whenever a pomter to ^j^^** signifi^ntly larger than the actual program 96 

^e mstanoe data 72 for an object 52 can be used to modify 15 stained in the program fill TTierefoie, such infonnation 

the contents of the object 52. Such mstructions also include ^„„. * ^a= • .u. i 

, . - , ^« musi be efficiently stored, 

second instructions to convert from a handle 68 to a pomter • • .j i- • ^ 

to the instance data 72. The second instructions are also used f ""P^'^^?^, % ^^^^ duphcaUng informaUon m njuL 

for "object faulting", as will be discussed in more detail f Pf°^r'! ° i '^^P^f'/ ' P^^ ^ 

below. Essentially, the second instructions examine the 20 54 that is already implemented by another ^^^^^^^^ 

object descriptor 70 of an object 52 to determine if the of the type mformation should be provided by program 

instance data 72 for the object 52 has been loaded into I not program A. If pro-am A implements a class 54 

memory. If not, the instance data 72 is loaded and the object ^ derived from a class 54 miplemented m program B, 

descriptor 70 is adjusted to include a reference to the loaded t^en Program A should only contam a description of the parts 

instance data 72 25 of the class 54 not contained m program B. 

As should be' understood, the model 16 of the present . ^ f ^ P^°g^^ essentially an array of 

embodiment is intended to be heterogeneously portable ^^^^^^ of some structure. Similar types of data ;^e saved 

across differing platforms 19, and the virtual machine 24 of ^ ^'"f structure, but different portions of the data may 

the present embodiment is necessary to interface the model depending on the specific data Rather than 

to a particular platform 19. However, one skiUed in the art 30 dumping the entire structure to a file it is preferable that the 

will recognize that in cerUin circumstances it may only be ^^'^ ^° ^^"ff ^^^P^ of a compacted 

necessary that the model 16 be homogeneously portable ^^^^^^^ ^^ at all possible, that can be recognized and recon- 

across substantially similar platforms 19. For example, it structed. 

may be the case that only one kind of work station will be Preferably, only changes in values in a data stream are 

used to access a model, and a user is willing to limit the 35 ^^ored. As should be understood, such a technique is espe- 

model to the one kind of work staUon. ^^^y ^^^^ ^hen a program 96 has many instances of a 

In such a circumstance, the need for a virtual machine 24 particular type of data, but each instance does not vary much 

is lessened if not eliminated. Instead, only a loader is from adjacent instances in a data stream. In such a situation, 

required to load a model 16 from a storage device, and a '^^'^ preferable that such data be represented with segmented 

translator or an interpreter may be required if the model 16 40 specifiers, 

is not in a platform-specific native code. Of course, one For example, and referring now to FIG. 15, if a list of 

skilled in the art will recognize that such a homogeneously 30-bit values is to be dumped to a file, each 30-bit list value 

portable model 16 may be employed while still being in the ™ay be divided into a 15-bit more significant field ("segment 

spirit and scope of the present invention. value") 98^ and a 15-bit less significant field ("offset value") 

45 98Z?, where the segment value is arranged into a 2-byte field 

Portable Programs ^jjjj ^ j^jj ^ ^f^^^ ^^^^^ arranged 

Preferably, and referring now to FIG. 14, each program or into a 2-byte field with a flag bit 98c set to 0. Accordingly, 

application 96 produced by the programming language 53 the segment value 9Ha need only be stored if such segment 

and the compiler 55 of the present embodiment is portable value 98fl changes as between adjacent list values, 

in the sense that the program 96 can be compiled on one 50 Thus, and as shown in FIG. 16, if a list contains seven 

platform 19 and run on other platforms 19 with different values where the first three list values share a first common 

operating systems 20 and/or different computer hardware segment value * A* and the last four list values share a second 

22. Preferably, each program 96 is compiled into an efiicient common segment value *B', the list can be stored as the first 

byte code format such as p-code (i.e. pseudo-code). segment value *A', the first three offset values 'C\ 'D', and 

In the present embodiment, and as was discussed above, 55 *E', the second segment value *B', and the last four offset 

the virtual machine 24 is part of the CMS kernel 12 and is values 'F', *G', 'H*, and *V. More importantly, when loading 

therefore written in native code. Accordingly, for each type the stored list of values, the flag bit 98c for each 2-byte value 

of supported platform 19, the virtual machine 24 and the determines whether the value is a segment value 98a or an 

CMS framework 14 are tailored specifically to such platform ofiEset value 9Sb, and the list can be reconstructed accord- 

19, and software must be provided for each type of platform 60 ingly. 

19 to generate such CMS framework 14 and virtual machine Preferably, data is organized intelligently based on seg- 

24- mented specifiers. Accordingly, data should be classified so 

Preferably, a program 96 that is to be run on the virtual that each classification has a different segment value 98a, 

machine 24 of the present embodiment contains code and segment values 98a rarely change in a stream of such 

segments, initialized data segments, descriptions of non- 6S data. Preferably, when the order of data is not important, 

initialized segments, relocation information, and additional such data can be sorted such that the use of segmented 

information that is required for transforming the program 96 specifiers optimizes the storage and retrieval of such data. 
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As one skilled in the art should now recognize, many commands that specify how to compute the value that is to 

different variations of segment specifiers may be employed be stored in the instructions or variables (i.e. the relocation 

without departing from the spirit and scope of the present value). The second group specifies how to store the data. The 

embodiment. For example, in some cases it may be better to first group sets the relocation value to either the address of 
use a 1-byte offset value 986 and a 3-byte segment value 5 an identifier representing a function or variable, the ofOset of 

9Sa. As should be evident, segmented specifiers may be * member variable 60 in a class 54 or structure, or the size 

employed for any type of data that is organized as pairs. * 'XP® retrieving the size of a type. 

To adjust for differences in how data is handled on More than one relocation command may be neces^^^^ 

different platforms 19, it is preferable that a program 96 that ^^2s\ ^tZT'^l^n^ to a member of a structure, 
mns on the virtual machine 24 of the present emb^^ lO Specifically, if the source code contains a reference 

have a complete descnpUon of the daU types employed. As ^j5yData.memberl.member2% then one instruction is used 

should be understood such descnpuon is required to ^ ^t^eve the data for such reference. As should be 

the layout of data defimUons. Such mformation is also understood, such instruction must be fixed up to take into 

required by the persistence manager 30, as will be discussed ^^^^^ j^e address of *myData' plus the offsets for both 

.... 'memberl' and 'member2'. 

After a program 96 is loaded, information in the program jq jj^ndle such a situation, it is preferable that relocation 

96 must be fixed up ("relocated") before execution. More commands are able to both set and add to a relocation value. 

specificaUy. relocation in the CMS 10 of the present embodi- s^ch a case, the compUer 55 would generate a relocation 

ment involves modifying instructions and data to reflect command that sets the relocation value to the address of the 

where in memory the program 96 is loaded, resolving ^^^.^^^^ ^^^^^^ ^^^^^^ ^^^^^ ^^^^ ^^^^^^^^ 

symbols from other programs 96, and taking mto account relocation commands that add the oflkets of memberl and 

other differences across platforms 19. member2 to the relocation value. 

As one skilled in the art should appreciate, information to The commands in the second group store the value 
be fixed up at run-time mcludes offsets of frame variables, computed by die command in the first group by including 
segment pointers, addresses of global variables and relocation data that specifies a type of operand and offset 
functions, and address of vanables and functions resolved j^io the segment. Preferably, if a relocation value is to be 
from dynamic libraries. Also, member offsets must be fixed stored in more than one location, chaining is employed. As 
since the layout of structures and classes 54 may be different should be understood, if the next location and the current 
at run-time than at compile-time, either because the program location are close enough tiiat the disUnce can be saved in 
96 is being run on a different type of platform 19 than that the cuncnt location, the current location is employed to save 
on which the program 96 was compiled, or because mem- the offset to the next location. If the next location is not close 
bers have been added to a base class 54. Further, since some enough, another command is added to the group of corn- 
instructions may rely on the size of a type, it may be mands specifying where the current relocation value should 
necessary to fix such instructions at run-time. be stored. As should now be evident chaining through the 

Conversely, register variables and function arguments are data reduces the size of the relocation data, 

preferably allocated the same way regardless of platform 19 Every element (i.e. class, template, function etc.) has an 

and therefore need not be fixed up at run-time. Since both are identifier. Preferably, identifier information is available at 

restricted to integral and floating point types, the ofeets of run-time in the form of a list of identifier entries which serve 
these variables cannot be affected by the changes in structure ^ as a focal point for all of the information regarding a 

sizes. function or variable. For example, reference can be made to 

Preferably, relocation is performed "up-front" when a the list of identifiers to determine how to layout memory 

program 96 is loaded, and memory used for relocation segments at run-time. Relocation entries can refer to iden- 

information is freed once relocation has ended. However, tifier entries to derive relocation values. A shared library can 
such up-front relocation requires appreciable processing ^5 employ identifier entries to retrieve addresses of functions 

time that may be perceived as a delay by a CMS user. and variables that are being made available to other pro- 

Accordingly, relocation for a given instruction or function grams 96. 

may be deferred until the instruction or function is executed. Depending on how an identifier entry is to be employed, 

Relocation information is preferably stored as a stream of different information is required on the identifier entry. To 
relocation commands. Accordingly, the relocation informa- 50 support portability, the loader (i.e. the part of the CMS 

tion is a prime candidate to benefit from segmented speci- kernel 12 that loads a program 96) (not shown) must know 

fiers. Three groups of commands are required for each type the offset, type, and segment for all identifiers. For some 

of information to perform the relocation on an instruction or identifiers, the loader may also need to know how a symbol 

variable: (1) a pointer to the target segment that contains the is to be resolved. For each frame identifier (i.e. an identifier 
target data, i.e. the data that is to be modified as a result of 55 for a variable that occurs within a function and is applicable 

the relocation; (2) an entry that specifies the data that is to only to the function), Uie loader must know the scope of the 

be stored in place of the target data; and (3) an entry that variable. For register variables, the loader must know the 

specifies the size of the target location and an offset from the oflset. 

start of the Urget segment. Preferably, identifiers are grouped according to certain 
Since large groups of relocation commands will refer to 60 attributes such that segmented specifiers or the like may be 

die same segment, the relocation commands are preferably employed. As should be understood, run-time code that 

grouped by target segment. Accordingly, one command processes such grouped identifier entries is simpler and more 

specifying the target segment applies to all subsequent efficient. Typically, all of die identifiers in a group are 

commands until the next command specifying a target processed in the same manner. Accordingly, code that pro- 
segment such that no segment is specified more than once. 65 cesses only a specific group need only be directed to that 

Hie subsequent relocation commands are arranged as group, and multiple passes over the various groups can be 

pairs of groups. Within each pair, the first group contains avoided. 
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Preferably, a list of identifiers that are exported (i.e. made as yet beea performed and none of the data has been 
available to other programs 96) is maintained apart from the adjusted to match the layout rules for the target plat- 
identifier groups. Such identifier entries should not be form 19. 

grouped since the export feature is usuaUy not the most Process all identifiers, calculating the sizes of the van- 
significant feature of the identifier. Instead, the list of 5 jbles on the target platform 19. 
identifiers is preferably indexed to the grouped identifier Calculate conversion operations for segments containing 

initiaUzed data. 

As one skiU«l in the art should recognize, a block of ^^^^ .^^^^ . ^ ^ ^ 

source code or scope m a C-type programmmg language understood, such allocation is only necessary for seg- 

slartsw.th a'{ and conunues untd the compder 55 encoun- lo ^^^^ ^ the external 

ters the matching } A frame variable is m scope untd the ^ .^^^^ ^ ^ .^^^^^ 

block ends. As should be understood, scope information is ^ ^ inHii&TtA data, or have initialized 

necessary when aUocaUng frame variables at run-lmie. ^^^^ ^ converted in place. 

A scope may be described by type (i.e. function or a block n • »u t *i- • ♦ i- t n r 

•»»_■ £. \ . r \ . IS Usine the addresses oi the internal images of all or the 

withm a function), name (if the scope is a fiincUon), starting " . . u ^ ^ r i^ j 

J J* : * 'J \'£L • * *i_ . • segments, set base addresses for groups of identifiers. 

and ending offsets to identify the instructions that are in the & > r 

scope, range of source code line numbers, and a list of Load all scopes and calculate ofl&ets of all frame vari- 

identifiers that are defined in the scope, among other things. 

However, for a program 96 to be portable for different Load all dynamic libraries including all required shared 

platforms 19, it is preferable that the only required data is the libraries. 

list of identifiers defined in the scope, and tiie ranges of the Fix byte order in all segments. 

instructions. As may be understood, the list of identifiers is ^pply relocation information. 

required so that firame variables can be allocated, and the ^ , ^ ^ , . • • « i 

ranges of instructions is required to determine nesting reU- ^^^^ ^^^""^ from external segments to mternal 

u- -.u *u ui iwtiiiiu 6* «. segments, adjustmg data layout as necessary, 

tionships with other blocks. ^ » j & ^ 

As one skilled in the art should recognize, an initialized information required to export symbols, 

data segment is a data segment that has been statically Load descriptions of data employed to install classes 54 

allocated at compile-time. For example, initialized data interfaces 56 firom the program 96. 
segments include mathematical constants and statically alio- 

cated objects 52 (discussed above in connection with ^° Object Management 

embedded objects 52S). Upon loading initialized data As was discussed above, an object 52 is an instance of a 

segments, a loader must convert the data to the formal particular class 54. As shown in FIG. 6, a class declaration 

required for the platform 19 where the program 96 will run. 64 for a class 54 defines the data structure of an object 52 

To facilitate such process, it is preferable that the data be instantiated from the class 54. That is, the instance data 72 

organized into separate segments for each data type. whichisassociated with any object 52 ofthe class 54 is laid 

Accordingly, segmented specifiers may be employed, and out and interpreted according to an instance data definition 

each data type in a segment is converted in the same manner. 100 for the class 54. The class declaration 64 for a class 54 

As should be evident, data conversion is more difficult also declares a set of methods 62 which can be applied to any 

when complicated structures are involved. In such a ^ object 52 instantiated from the class 54. All objects 52 of a 

situation, it is preferable that a list of identifiers is provided class 54 share the same instance methods 62. However, each 

which describes each structure in a segment, and the list is object 52 is a distinct entity with its own storage for instance 

employed to create data conversion operators that describe data 72. 

the transformations needed to convert the data for the target As was also discussed above, and as shown in FIG. 8, 

platform 19. As should be understood, conversion may every object 52 is represented by an object descriptor 70 

involve fixing byte order (i.e. whether the most or least which has references to instance data 72 for Uie object 52 

significant byte of a value is first) and/or moving data if the and a class object 52C that embodies the class declaration 64 

structure layout is different on the target platform 19. for the class 54. Instance data 72 for a first object 52 may 

Preferably, the loader of the CMS kernel 12 of the present include a reference lo a second object 52 by pointing to the 

embodiment loads the different sections of a portable pro- object descriptor 70 for the second object 52. Preferably, the 

gram 96 according to the following procedure: virtual machine 24 of the present embodiment allows an 

Load the header file for the program 96. As should be object pointer to refer to an object 52 of a different class 54, 

understood, the header file includes information on the and determines the class 54 of the referred-to object 52 

characteristicsof the platform 19 where the program 96 dynamically at run-time whenever access to the member 

was built, including byte order in the program 96. variables 60 or methods 62 of the object 52 is required. 

Load all data used to describe the program 96, including As also shown in FIG. 8, instance data 72 is associated 

directories to the remainder of the program 96, a string indirectiy with the object descriptor 70 of an object 52 by 

pool, type information, groups of identifier entries, way of an instance data reference 74 in the object descriptor 

initialized segments, information on scopes, a list of 70 for the object 52. Accordingly, instance data 72 may be 

dynamic libraries, relocation information, a list of 50 reallocated, deleted from memory, or swapped out of 

identifiers to be made available to other programs 96, memory temporarily without disturbing any references to 

and data structures that must be initialized to install the object descriptor 70 by way of the handle 68 for the 

classes 54 and interfaces 56 from the program 96. object descriptor 70. 

Initialize the type system calculating the sizes and align- Since an object pointer holds the address or handle 68 of 

ment for all of the types. 65 an object descriptor 70, and not instance data 72, an object 

Load initialized segments. As should be understood, all of pointer cannot be manipulated like a structure pointer. In 

the segments are in external format. No relocation has particular, an object pointer is not assignment compatible 
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with or convertible to any other kind of pointer. Therefore, 
addresses derived from an object pointer cannot be used for 
data access in any way, and object pointer arithmetic cannot 
be reliably performed based on an object pointer. 

As explained above in connection with embedded objects 
52S, the instance data definition 100 of a class 54 may also 
be used to declare an embedded object 52S (i.e. a statically 
allocated embedded object). An embedded object 52S is not 
represented by an object descriptor 70. Instead a temporary 
object descriptor TOT is created to allow the embedded 
object to invoke instance methods 62. However, a temporary 
object descriptor TOT is not required to access the member 
variables 60 of an embedded object 52S. 

Preferably, and again referring to FIG. 8, the object 
descriptor 70 for each persistent object 52 in the model 16 
can have a back-pointer reference 78 to a list of back- 
pointers 80. As seen, each back-pointer for a target object 52 
(represented by OBJECT DESCRIPTOR 2 in FIG. 8) refers 
to a source object 52 (represented by OBJECT DESCRIP- 
TOR 1 in FIG. 8) that includes as instance data 72 a pointer 
101 to the target object 52. Preferably, the list of badc- 
pointcrs 80 for a target object 52 is maintained indepen- 
dently of the instance data 72 for the target object 52. 

However, if a target object 52 holds only one back-pointer 
80, the object descriptor 70 for the object 52 preferably 
includes a reference directly to the source object 52, without 
requiring a back-pointer list 80 to be created. Accordingly, 
overhead memory for such unnecessary badc-pointer list 80 
is avoided. 

A back-pointer list 80 for a persistent object 52 is pref- 
erably created on demand, and the list can be dynamically 
extended as necessary. Preferably, the list of back-pointers 
80 for a target object 52 is updated whenever a reference to 
the target object 52 from a source object 52 is added or 
deleted. The list of back-pointers 80 for each object 52 must 
be current by the end of a transaction, when the model 16 
must be in a consistent state for purposes of change 
validation, to be described below. Preferably, the transaction 
manager 46 of the framework 14 performs back-pointer 
maintenance automatically as part of change validation. A 
CMS programmer or user may also call run-time system 
functions to update a back-pointer list 80 at other times. 

To maintain the integrity of a model 16 based on persis- 
tent objects 52, the list of back-pointers 80 for each object 
52 must be made persistent with the object 52 (as shown in 
FIG. 19) such that known dependencies of other objects 52 
are preserved. Accordingly, when the object 52 is loaded 
from a store 18 and changed, dependent objects 52 are also 
loaded (if necessary) and then notified of the change. 

As should now be understood, the list of back-pointers 80 
is necessary along with "forward" pointers 101 to maintain 
two-way references between objects 52. For example, if a 
"source" object 52 holds a pointer 101 to a "target" object 
52 and the target object 52 is to be deleted or changed, the 
target object 52 needs a back-pointer from the back-pointer 
list 80 to the source object 52 to notify the source object 52 
of such deletion or change. Accordingly, the source object 52 
may react to such deletion or change in a pre-defined manner 
according to methods 62 associated with the source object 
52. 

Specifically, when data for an object 52 has been 
modified, data in dependent objects 52 may also have to be 
modified. Moreover, other data in the modified object 52 
may have to be modified. Preferably, such modification 
occurs during a "validation" procedure that is deferred until 
an appropriate time. To facilitate such deferred validation, it 
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is preferable that whenever an object 52 is modified, the 
"change bit" 102 in the object descriptor 70 for the object 52 
is set, as seen in FIG. 12 and as was discussed above. 
Accordingly, the modified object 52 is scheduled for 

5 deferred validation. Preferably, the validation process is 
performed at the end of each transaction and is initiated by 
the transaction manager 46 of the framework 14. 

After all direct changes have been made by a CMS user, 
a run-time system function is called to start the validation 

10 process. Preferably, and as shown in FIG. 17, the validation 
process starts with the compilation of a list of objects that are 
to be validated (S1701). Each object 52 has a validation 
method which is invoked when the object 52 is validated. 
After the first object 52 in the list is validated (S1702), the 

1^ change bit 102 for the object 52 is cleared (S1703) and a 
change notification is sent to each source object 52 on the 
back-pointer list 80 for the cleared object 52 (S1704). If 
there is a next object 52 on the list to be validated (S1705), 
the next object is validated (S1706), the change bit 102 for 

20 the next object 52 is cleared (S1703) and a change notifi- 
cation is sent to each source object 52 of the cleared next 
object 52 (S1704). As should now be understood, each 
additional object 52 in the list is similarly validated. 

Since validation of one object 52 may produce further 
modifications to other objects 52, the validation process 
preferably proceeds in waves. Specifically, once the end of 
the list is reached, the validation process determines whether 
other objects 52 must be validated as a result of the preced- 
ing validation wave (SI TOT). If so, a next validation wave 
(steps S1T01^1T06) takes place. As may be understood, 
then, the same object 52 may be validated more than once 
in a single validation process. The process continues until no 
more objects 52 are marked changed, or until a maximum 
number of iterations has been reached (i.e. to avoid cycling). 
Accordingly, it is preferable that a wave counter be iterated 
(S1708) before each subsequent wave, that the validation 
process be terminated if the wave counter reaches a pre- 
determined maximum value (S1709), and that the CMS user 
be notified (S1710) if the validation process has terminated 

^ to avoid cycling. 

Preferably, a CMS user may add consistency rules to an 
existing schema SO, and the consistency rules are invoked 
during the validation process. Such consistency rules are 
typically associated with an object 52 or a class 54, and may 
for example limit a member variable 60 to a predetermined 
range. 

If an invalid change is detected during the validation 
process, an "exception" is preferably signaled. An exception 
50 during the validation process preferably triggers the trans- 
action manager 30 to reverse all effects of the current 
transaction. 

Object Persistence 

S5 The potential lifetime of an object 52 likely will exceed a 
single CMS user session. Accordingly, the object 52 must be 
made "persistent". Preferably, the programming language 53 
of the present embodiment is a "persistent programming 
language" which makes persistence non-class-based and 

60 which manages object storage and retrieval transparently. 
For a definition of persistent progranuning language, see 
Antony L. Hosking and J. Eliot B. Moss. "Object Fault 
Handling for Persistent Programming Languages," Proceed- 
ings ACM Conference on Object-Oriented Programming 

65 Systems, Languages and /^plications. Washington, D.C., 
September 1993, pp. 288-303, hereby incorporated by ref- 
erence. To achieve true object-oriented persistence, each 
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persistent object 52 in the model 16 is preferably assigned a 
unique, persistent identity. 

As shown in FIG. 18, the persistence manager 30 in the 
CMS kernel 12 preferably binds an object 52 to a particular 
persistent store 18 by creating an explicit linkage between 
the object descriptor 70 of the object 52 and the store 18. 
More particularly, the object descriptor 70 contains a per- 
sistence binding tag reference 104 to a persistence binding 
tag 106 that in turn contains a persistent store reference 108 
to the particular persistent store 18. Preferably, the persis- 
tence binding tag 106 also has a tag ID 110 for the object 52 
that is unique in the persistent store 18. 

Preferably, persistence is an optional property which can 
be added to any object 52. An object 52 that has not been 
bound to a store 18 is transient and will have no persistence 
binding. A non-persistent object 52 can be made persistent 
by binding such object 52 to a store 18, and a persistent 
object 52 can be made transient again by dropping such 
object 52 from the store 18. Accordingly, an object 52 can 
be "moved" from one store 18 to another if so desired. 
Preferably, any object 52 which is referenced by a persistent 
object 52 will be made persistent automatically, as explained 
below. 

The tag ID 110 of a persistence binding tag 106 of a 
persistent object 52 is preferably assigned to the object 52 at 
the time the object 52 is first bound to a store 18, and is 
unique within the store 18. A persistent object 52 can 
therefore be queried for its tag ID 110, while a non-persistent 
object 52 cannot be similarly queried. An object 52 can be 
bound to at most one store 18 at a time. 

Preferably, storage of instance data 72 is done automati- 
cally using the data definition 100 specified for the class 54 
of the object 52, as illustrated in FIG. 19. Since the class 54 
of an object 52 may be a derived class 54 and the data 
definition 100 of the class 54 includes the daU definition 100 
of a base class 54, it is preferable that the combined data 
definition 100 be detected and that the object instance data 
72 be saved accordingly. Nevertheless, a schema developer 
may extend or override such data storage mechanism selec- 
tively if the structure-oriented data definition is too restric- 
tive. As a result, persistence of a single object 52 may be 
partly handled by system logic and partly by custom logic, 
and custom logic may be introduced by multiple derived 
classes 54 in a modular way. 

Preferably, the CMS 10 of the present embodiment sup- 
ports the automatic reading and writing of all data types by 
the object/persistence manager 30 of the CMS kernel 12. 
Nevertheless, it may be the case that certain "C" data types 
such as unions, bitfields, and non -object pointers are not 
supported. Accordingly, if a class 54 introduces unsupported 
member variable types, such class 54 must also provide 
methods for serializing its stale. As should be understood by 
one skilled in the art, an example of a class 54 which uses 
serialization is a class 54 that includes a definition for a 
variable-length list data structure, which keeps a resizable 
array of data in dynamic memory, plus a count. When 
storing and loading an object 52 of such a class 54, the CMS 
10 preferably defers to the array to serialize its data 
members, based on the count. 

A designer of a class 54 may wish to control how the state 
information introduced by the class 54 is stored. For 
example, and as one skilled in the art should appreciate, the 
designer may want to compress a rotation matrix variable to 
a quaternion representation on disk. Preferably, each class 
54 can take over control of the storage of defined member 
variables 60 from the persistence manager 30 by defining 
two specially named methods, 'StoreSubStore' and 'Store- 
SubLoad*. 
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For example, if a class is defined to include a member 
variable 60 of a type which is not supported by the persis- 
tence manager 30, such class B must also define the methods 
'StoreSubStore' and 'StoreSubLoad' to allow for storage of 
5 the unsupported type: 

class B: Object 



char *aL^; // unsupported data type 

void StoieSubStore (DataStream*) ; 

void StoieSubLoad (DataStream*) ; 

); 

15 

The persistence manager 30 detects and invokes such meth- 
ods whenever instances of class B are written to or read from 
disk. Accordingly, such methods become an extension of the 
persistence manager 30 without which objects 52 of class B 

20 cannot be persistently managed. 

Overriding is preferably incremental. Each derived class 
54 in a class hierarchy can control storage of the portion of 
the instance data 72 defined by such derived class 54, 
independently of other derived classes in such class hierar- 

25 chy. Preferably, the CMS 10 of the present embodiment 
supports a mixture of standard and customized storage of 
instance data 72 within a single class 54. When loading and 
storing instance data 72, the persistence manager 30 auto- 
matically handles instance data variables introduced by 

30 derived, classes 54 within a class hierarchy which do not 
implement serialization, and invokes the serialization meth- 
ods of all derived classes 54 that do implement serialization 
methods in top-down hierarchy order. 
As seen in FIG. 19, since each persistent object 52 has a 

35 tag ID 110, object pointers 101 between objects 52 may be 
saved and restored persistently. To save ' a pointer 101 from 
a source object 52 (represented by OBJECT DESCRIPTOR 
1 in FIG. 19) to a target object 52 (represented by OBJECT 
DESCRIPTOR 2 in FIG. 19), where the source object 52 is 

40 to be stored in a persistent store 18, it is preferable that the 
pointer 101 be replaced with the tag ID 110 of the persis- 
tence binding tag 106 of the target object 52 (*tag2' in FIG. 
19) prior to storing the instance data 72 for the source object 
52 in the persistent store 18. Similarly, to resolve the pointer 

45 101 once the source object 52 is restored, the stored tag ID 
110 is employed to look up the object descriptor 70 of the 
target object 52. Such encoding and resolving of pointers 
101 and tag IDs HO ("swizzling"), is preferably done 
automatically. Only pointers to objects 52 can be swizzled. 

50 Accordingly, if an object includes a pointer to non-object 
data, the non-object data must be saved with the object 52 
by way of the *StoreSubStore' and 'StoreSubLoad' I/O 
methods discussed above. 
Unlike prior art modeling systems, the integrated persis- 

55 tent CMS 10 of the present embodiment captures and stores 
the complete definition of each object 52 including a class 
declaration 64, class methods 62, and instance data 72. 
Accordingly, a class 54 may be reinstalled and methods 62 
may be reloaded from a store 18 as necessary to restore a 

60 stored persistent objects 52 to a live, running state. 
Moreover, by storing objects 52, classes 54 and methods 62 
together, the necessary supporting software and resources 
are always delivered along with objects 52 when the model 
16 is copied or moved. Only the CMS kernel 12 is required 

65 to open and work with the persistent model 16, regardless of 
where the model 16 was built or the tools or programs 96 
that were used to build such design. Since the model 16 



01/08/2004, EAST Version: 1.4.1 



6,063,128 

45 46 

contains everything necessary for execution within the vir* A project presents a single set of model objects 52 to a 

tual machine 24, the model 16 will continue to work in the CMS user Preferably, objects 52 in one store 18 can refer to 

future. objects 52 in another. All objects 52 are potentially 

Preferably, the persistent model 16 constructed by a CMS modifiable, as all stores 18 in a project are potentially 

10 of the present embodiment is binary portable in that 5 read/write. Stores 18 may be added to a project as the project 

objects 52 created and stored on one platform 19 may be progresses and may also be shared among different projects, 

reloaded and used on another platform 19 without recom- j^^ project model 16 is therefore a generaUzation of the 

pilmg or conversion of any kind. As was discussed above. ^^^^^^^^^ ^^^^ ^ ^^^^^ ^^^^^ 3 

however, it is expected that each type of platform 19 must j,^,, „ r -^^l- 

have a platform-specific copy of the CMS kernel 12 to use ^h^ P^^i^^ '^<^^^ ^l^^^s for a unified history 

the persistent model 16. mechanism for jouroalmg changes to objects 52 across the 

When an object 52 is added to a persistent store 18, it must ^^^^ 1^ i° * project. Such changes are preferably noted in 

be ensured that the class 54 of the object 52 is also persistent « ^^^^ project history file. Accordingly, the history mecha- 

in the same store 18. If the class 54 is not persistent, the class maintains a persistent ''undo" buffer for the project. 

54 must be made persistent, as explained below. Preferably, In a project, and as seen in FIG. 20, one store 18 in the 

and as seen in FIG. 19, each persistent object 52 is stored project database 17 is preferably designated as the root store 

with at least a portion of the persistent binding tag 106 for 18R. The root store 18R includes a project object 52P which 

the object 52 (tag ID 'tagl'), and at least a portion of the contains the names and file locations of all other stores 18 in 

persistent binding tag 106 for the class object 52C of the the project, plus the name and location of the project history 

class 54 of the object 52 (tag ID 'tag3*). Accordingly, the file. The project object 52P is explicitly located by a known 

stored persistent object 52 includes a persistent reference to persistence binding tag 106 or a special alias. A project is 

the class 54 of the object 52 by which the class 54 can be opened, then, by a user identification of the project root store 

resolved and possibly reinstalled when the object 52 is 18R. The CMS kernel 12 can then "bootstrap" the project by 

restored later. connecting to the information in the project object 52P. 

To make a class 54 persistent in a store 18, the code jhe project model 16 insulates inter-file references from 

libranes which contain the definition and implementation of 25 ^y^j^^j network dependencies and aUows stores 18 to 

the class 54 must also be persistent in the store 18. If the be renamed or moved without breaking links. Preferably, 

code libraries are not persistent, the libraries are stored, as each store 18 resides in a file 112 and each store file 112 is 

explained below. The class 54 is then registered by name, assigned a persistent, globaUy unique store identifier 114 

and an entry which represents the class 54 holds a persistent vvhicti is saved in a header for the store file 112. A reference 

reference to the associated programs 96, which are typically 30 ^ ^^^^^ ^^^^^ ^ ^^^^^^ ^^^^^ ^j^^^^ defined 

shared libraries. Accordingly, the class 54 can be looked up in terms of the target store identifier 114 and not by file name 

by name at load time and can be installed. location. 

To make a code Ubrary pei^istent in a store 18, an image ^j^, references at run-time, the project 

of the library IS saved as bmary data to the store 18. object 52P preferably mainUins a record for each store file 

AdditionaUy, all other hbranes imported by the code hbrary 35 ^ ^ ^^^^ ^ 

are made pe^istentm the same store 18, and dependenaes ^4 ^j^^ ^ ^ 

are persistenUy noted. Run-Ume system services can then be ^ gj^^ object 52P is ^e only 'place where 

invoked to load the code program direcOy from the store 18 .jore files 112 are knowD by name, a store fite name and 

at load time, as explained below^ „ location mt«t be updated to the project object 52P if the Store 

Objec uKtance data produced by each program 96 is « ig ^ references mtist be 

preferably stored in a standard, neutral data format, regard- , gj^^ project, 

kss of where such object instance data was created. For s* r J 

multi-byte data, the standard is preferably Little Endian, Workspace Model 

IEEE format, although one skilled in the art will recognize „ , ui .u ^.o.n r l l j- . ■ 

that other formats may be employed without departing from « Preferably, the CMS 10 of the present embodmient imple- 

the spirit and scope of the present invention. Data is usuaUy ' workspace model for workmg with objects 52. 

stored in "packed" (unaligned) form to minimize required """"'l distinguishable from the 

memorv soace ^ «^ ' project model 16. In the workspace model, methods 62 are 

As should be evident, using a standard format for storage ^1?^^°^"?^ modify objects 52 in memory, modified objects 

makes translation straightforward: object daU being stored 50 52 are detected and committed as a group to permanent 

is converted from native format into standard format, and fi^^'^e J^,^^^ ^^J^^ ^2 '^^^ ^"^"^ 

object data being retrieved is converted from standard the Project model 16 mto memory and restored to a runmng 

format into native format. Of course, when the native format f^'^' ^"'^^f *^ .^^^^^^ on demsmd and transparently 

matches the standard format, no conversion is required. through the mechanism of object faulung, as wiU be 

Since the standard format is packed, it is almost always ^5 acscriDco Deiow. 

necessary to relocate (i.e. "unpack") instance data to meet above-described workspace model, the corre- 

native structure alignment mles. Preferably, conversion and spending project model 16 always contains a complete, 

relocation are never a concern of the schema 50. coherent set of objects 52. Also, objects 52 are always "in 

memory" from the point of view of the CMS programmer 

Project Model ^ and the CMS user. Further, platform memory usage is 

Persistence is organized around the concept of a "project". minimized, and very large models can be manipulated even 

A project is a grouping mechanism for using multiple when memory is limited. 

persistent stores 18 to define a set of related objects 52. The As was discussed above, the CMS kernel 12 of the present 

model 16 is a project model that defines a file set that can be embodiment marks an object 52 as "changed" whenever the 

moved in entirety or from which individual files can be 65 member variables 60 of the object 52 are modified, 

moved or renamed without breaking links or dependencies Preferably, a "save" operation writes each changed object 52 

among objects 52 and resources within the project. to the proper persistent store 18 for that object 52. Ehiring the 
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write operation, pointers 101 in the changed object 52 are 
swizzled, and references to other objects 52 are detected. If 
a referenced object 52 is not persistent, the CMS kernel 12 
automatically makes the referenced object 52 persistent and 
binds the referenced object 52 to the store 18 of the changed 
object 52. Accordingly, a CMS programmer need not be 
concerned with specifically making each object persistent. 

Preferably, and with reference to FIG. 21, a persistent 
object 52 can be in one of three states in the workspace 
model: potential, where no object descriptor 70 is in memory 
and the class 54 of the object 52 is not installed in memory; 
non-resident, where an object descriptor 70 for the object 52 
is in memory and the class 54 of the object 52 is installed in 
memory but no instance data 72 is in memory; and resident, 
where an object descriptor 70 for the object 52 is in memory, 
the class 54 of the object 52 is installed in memory, and the 
instance data 72 is in memory. As should be understood, if 
instance data 72 is not in memory, such instance data is 
stored in a store 18 in a storage device. 

Preferably, connecting to any object 52 causes the virtual 
machine 24 to create an object descriptor 70 for the object 
52 and to associate the descriptor with the persistence 
binding for the object 52. If the class 54 of the object 52 is 
not already installed, the CMS kernel 12 installs such class 
54 from the storage device, as described below. The instance 
data 72 for the object 52 is preferably not read in from the 
storage device, and the instance data reference 74 in the 
object descriptor 70 is NULL. 

To re-instate the run-time environment (i.e. the class 
declaration 64) required for the connected-lo object 52, the 
persistent reference for the object 52 is obtained by way of 
the object descriptor 70 and is followed to the stored entry 
for the class 54 of the object 52 and then to the required 
programs 96 which are guaranteed to be saved in the same 
store file 112. The persistence manager 30 then invokes a 
run-time system function to load the required programs 96 
directly from the store 18. If a program 96 requires any 
shared libraries, such shared libraries are loaded first. As the 
libraries are loaded, classes 54 defined in the libraries are 
installed in the run-time environment. With the connected-to 
object 52 having an object descriptor 70 and an installed 
class 54, the object 52 is non-resident. 

An "object fault" or object load is preferably triggered 
whenever the instance data 72 of a non-resident object 52 is 
accessed. An object fault is handled by the persistence 
manager 30 of the CMS kernel 12 by allocating memory, 
reading the instance data 72 for the object 52 from the 
appropriate store 18 into memory, swizzling the pointers 101 
in the instance data 72, and setting up the instance data 
reference 74 of the object descriptor 70 to the instance data 
72 for the object 52. Accordingly, the faulted-in object 52 is 
resident. 

Preferably, the swizzling of the pointers 101 in the 
instance data 72 of an object 52 causes the CMS kernel 12 
to connect to all referenced objects 52, as seen in FIG. 21. 
Accordingly, object descriptors 70 for such referenced 
objects 52 are aeated and classes 54 of such referenced 
objects 52 are installed. Such referenced objects 52 are left 
in a non-resident state until faulted in. 

When a program 96 opens a project root store 18R, the 
CMS kernel 12 preferably connects to the persistent project 
object 52P. The project object 52P contains references to key 
objects 52 in the project. Therefore, once the project object 
52P is faulted in, the high-level objects 52 to which the 
project object 52P directly refers are connected to and 
become nonresident, and all other objects 52 in the project 
are reachable from such key objects 52. 
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Since all references to objects 52 are to object descriptors 
70, and since object descriptors 70 point indirectly to 
instance data 72, the virtual machine 24 of the present 
embodiment may discard unmodified instance data 72 and 

5 rely on the object faulting mechanism to re-read such 
instance data 72 when required. Accordingly, allocated 
memory can be freed up if need be. Note that object 
descriptors 70 cannot be freed or discarded from memory 
while still in use. 

Preferably, the CMS kernel 12 of the present embodiment 
allocates all (non-temporary) object descriptors 70 out of a 
special heap. The heap brokers system memory in large 
chunks for space and time efficiency. Since the heap is 
specialized and since object descriptors 70 are all one size, 
per-descriptor memory overhead is virtually eliminated and 
allocations and frees can be performed quickly. 

As was discussed above, the "save" operation writes a 
new version of the project model 16, defiiied as the state of 
all changed objects 52. Preferably, before a new version is 
written, the existing state of aU changed objects 52 is 

20 archived in the project history file which is associated with 
the project. Accordingly, archived versions of the project 
model 16 accumulate in the history file. Preferably, the CMS 
10 of the present embodiment implements a "roll-back" 
operation to reinstate an archived version of a project. As 

25 should be understood, a roll-back discards all affected 
objects 52 (making them non-resident) and designates the 
project history file as the source of data for faulting in such 
discarded objects 52. Of course, roll-back clean up frinctions 
must be called before and after a roll-back operation is 

3Q performed to clean up side effects. 

Properties 

As one skilled in the art will recognize, many high-level 
external languages define the concept of a "property*', as 
distinct from a method 62. Essentially, a "property*' can be 
defined as anything that describes a feature of an object 52. 
For example, if the object 52 is a circle, one property of the 
circle may be a center point. 
,,yttPreferably, the CMS 10 of the present embodiment allows 
a schema developer to define a buiU-in property by declaring 
40 a pair of methods which mediate "get" and "set" access to 
the value of the property. Accordingly, pr operty acces s 
rcquestSL gay be forwarded to such access met fiods. Property 
access methods may also be called directly. A schema 
developer may then publish methods for built-in p roperties 
45 by usin g a special nami ng co nvention, as ismorS fully 
desc ribedfin SO M ObjectstyeveloBfi r Toolkit: Users Guide 
(Version i.O), hereBy incorporated by reference. The method 
names may then be parsed to determine the name of the 
property and to identify the get and set access methods. ' 
50 In addition to built-in properties, a CMS end user may add 
properties to an object 52. Preferably, an added property is 
defined by a name, a data type, and a default value. If the 
name of an added property conflicts with the name of a 
built-in property, the added property preferably takes pre- 
ss cedence. 

As shown in FIG. 22, properties arc preferably added to 
all objects 52 of a class 54 by adding an auxiliary data 
definition lOOA to the instance data definition 100 for the 
class 54, and by appending the property values 72A to the 
^0 instance data 72 of all objects 52 of the class 54. Per-class 
property values 72A are persistently stored with each object 
52 of the class 54, and the auxiliary data definition lOOA is 
persistently associated with the class 54. 

g5 Remote Objects 

The preferred embodiment of the present invention 
described above serves as a tedinolc^y base to solve a 
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Specific mcxleUng problem: managing distributed compo- Scenario 1 

nents or sub-components of a model. The programming A user wishes to purchase an "off the shelf* component to 

language 53, schema environment and persistent model complete an engineering model. The user logs on to an 

management systems of the present embodiment provide an engineering data gateway (shown in FIG. 24) and queries for 
enabling technology for a new class of CMS component 5 all components matching the required component specifica- 

called "remote objects". tions. Preferably, the gateway allows the user to link up to 

In traditional geometry-based CAD systems, files used to the manufacturer/distributor of the desired component. Once 

model an engineering project typically contain all the con- chosen, the schema SO of the component interacts with the 

stituent components of the model 16. In some cases, it is project database of the user, 

necessary to reorganize one large file into many smaller files Scenario 2 

that correspond to logical subdivisions of the engineering a user issues a command for the CMS to generate an 

project (e.g., reference files). In some cases, these smaller up-to-date biU of materials necessary to construct a model 

files could be "distributed" out to different server machines, 16. Preferably, each component in the bill of materials 

but rarely beyond the expanse of a single local area network initiates a link-up to the manufacturer of the component to 
since limits are imposed by file system access, is p^vide up-to-date pricing and avaaability information. 

Unfortunately, the granularity of these "distributed" subas- jhus, the user can be alerted of price changes, problems with 

semblies is always governed by the attributes of the model availability of the component, and the like, 

itself. It is not usually possible to organize and distribute the Scenario 3 

subdivisions of the model 16 based purely on attributes of * ^ ^^i ^««*„;„- i, 

. .-^ . . .1. t- A user has a live engineenng model contaimng network 

Oie coDstituent »mponenU Furthem^^^ these subassem- 20 «, eDts on a lap-top or pen computer but is not currenUy 

blies were only distnbuted as to ttieir locatK,n In reality. connected to any interactive network. Preferably, the CMS 

the distinction of location is lost because the full contents Ai^^^^,.^ /u^ -^4, i 

J . ^ r .t. . t- . .Li . 1(1 displays the latest version (last refreshed) of the network 

and structure of the file must still be visible to the CAD ix7k„« ♦v,^ L ^ »^«c ^ u .u 

components. When the user re-connects to a network, the 

program. engineering model is once again "live". 

In a CMS, a user or programmer may wish to package ^he scenarios described above lead to the following 

components of an engmeermg model by any of an endless requirements. The CMS 10 must be able to query the 

set of criteria and distribute the packaged components to interactive network for available remote objects 52R and 

remote locations where the admimstration of the compo- standards governing classes 54 of remote objects 52R. 

nents is more manageable (e.g., for reasons of available AdditionaUy, the CMS 10 must be able to retain information 

expertise or perhaps secunty). In such a case, access from ^^^^ j^e source or origin of each remote object 52R 

the parent model to remotely distributed components may (location on the interactive network) and view a model 

need to be restncted and mediated according to carefully containing the remote object 52R when not connected to the 

fonnulaled protocol Accordingly remote objects 52R network. A remote object 52R should be of the same class 

(shown m FIG. 23) may be employed to effect the regulated 54 whether physically local to or remote from the model, 

mteracaon between the local model and its distributed Preferably, a refreshed version of a remote object 52R is 

components. loaded from the network only occasionally and a user can 

"Remote" in the context of a remote object 52R is a select when a refresh will occur (immediately, upon demand, 

relative term. The "distributed" components may in fact be daily, weekly, quarterly, etc.). 

in the same building or even reside on the same physical An implementation of the CMS 10 that fulfills the above- 
machine as the parent model. Access may simply be specified requirements is shown in FIG. 23. As seen, a user 
restricted by the way a file system is set up. Conversely, cMS lOU includes a model 16 and is interfaced to one or 
"remote" might mean that the components reside on a more external sites 116 on a network U8 by way of 
computer on one continent whUe the model resides on a weU-known interfacing means. As should be understood, 
computer on another continent. In such a situation, an each site 116 contains at least one schema 50 representing 
mteractive network such as the Internet or the like must be available components. Preferably, the connection between 
employed as a communications medium between the two the user CMS lOU and the external site 116 is not essential 
computers. to viewing the model. 

Conceptually, in the CMS 10 of the present embodiment, ^'^Vf As should now be understood, each object 52 in the model 
remote objects 52R have corresponding local and remote 50 contains data representative of a model component, and a 

portions that represent two "halves" of the same object 52R. reference to the class 54 of the object 52. Each class 54 

Some of the contents of the object 52R may reside locally defines the instance data 72 associated with each object 52 

whereas other parts may reside remotely. As a first example, and available methods 62. Preferably, for purposes of effec- 

the local half of the remote object 52R may contain all tuating remote objects, each class 54 also maintains a 
information relating to geometric representation of the 55 reference to an associated class origin object 120. Each class 

object 52R, while the remote half of the object 52R may origin object preferably includes location information 122 

contain up-to-the-minute inventory information about the and flags 124. If the class 54 originates from an external site 

object52R.Asasecondexample, the local half of the object 116 (e.g., a component manufacturer web site on the 

52R may contain a complete copy of all information relating Internet), the location information 122 includes a locator for 
to the object 52R, whUe the remote half of the object 52R is go the site 116 sudi as a universal resource locator (URL), and 

accessed only to update the local half of the object 52R as the flags 124 signifying how often the class 54 should be 

necessary. The two halves of the object 52R coordinate and refreshed from the external site 116. If the class 54 is local 

communicate with each other through the invocation of to the model, the location information 122 reflects such 

methods that are defined and executed in their local context. information and the flags 124 signifying that a refresh 

The following scenarios describe how the subject matter 65 operation is not necessary, 

of the present embodiment applies remote objects 52R to the If a user request an up-to-the-minute bill of materials, for 

engineering modeling domain: example, the CMS preferably contacts each external site 116 
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referenced by a class origin object 120 in the model, and a static kernel executing on the platform and interfaced to 

class declaration 64 and/or instaooe data 72 in the model 16 the operating system and the computer hardware, the 

and relevimt to the external site 116 are refreshed. The j^ernel for providing services necessary to load and 

pseudo-oode for a refresh operation is: ^^^^^ ^^^^ .^^^^^^^ ^^^^^^ 

^ services; and 

^— — — — — — — a dynamic framework executing on the platform and 

i a bSl or^eSur"" ^" interfaced to the kernel, the framework for providing a 

for each object; platform -independent visual interface between the 

follow class reference in object descriptor CMS and a CMS user, the framework employing the 

u> class origiQ object for the object; . r i « j 

if class ori^ object shows object services of the kernel; and 

origuiatcd from an external site; a project database having a persistent store, each persis- 

^e^ contact external site for current component object in the portable persistent model 

else object already has current data; being instantiated from a class within a schema and 

end for* ^ being Stored in the persistent store with the schema. 

// each object has current data; 2. The system of claim 1 wherein the first platform 

generate the btii of materials; executes a particular type of native code and wherein the 

^"■^^""^^"^^"""^^^^^""■^^^^^ kernel is provided in the form of the native code. 

As shown in FIG. 24, when a user on a user CMS lOU is 2° 3- The system of claim 2 wherein the kernel exposes a 

designing a model 16 and needs to find a specific component function call-based application programmer interface having 

for the model 16 from an external network site 116, a native code functions, the native code functions being acces- 

browser 126 such as an engineering data web browser is sibig by direct calls from the framework, 

preferably employed to log into a gateway 128 such as an ^ ^j^^ ^ ^^^^^ ^^^^^1 

engmeermg data gateway. As seen, the engineermg data 25 . •[ . a»*v* wo « 

gateway 128 has a database of component manufacturers ^^^^ machine. 

130 and is mnning a CMS virtual machine 24 and kernel 12 5. The system of claim 4 wherein the virtual machine is 

(not shown). Preferably, the user sends a component search platform-dependent. 

request 131 to the gateway 128, the virtual machine 24 on 6. The system of claim 5 wherein the virtual machine 

the gateway 128 downloads a component selection program 30 interprets platform -independent code. 

^"^c in/;''°'^\^''"''^'^''i'^' information 134 to the 7 ^i^^^ 5 ^^erein the virtual machine 

user CMS lOU, and the user selects a component manufac- , -j ^ - . t 

turer based on user-defined component specifications 136. f^^^f^ platform-independent code into platform- 

Pireferably, the selected component manufacturer has an ' ^ , . 
external network site 116 that is mnning a CMS virtual 35 ^' ^5^*^^° ^1^"° ^ ^^^^"^ ^^^"^^ ^^"^^ i° 
machine 24 and a kernel 12 (not shown), and the engineering ^ platform-mdependent object-oriented schema implemen- 
data gateway 128 turns over control to such site 116. The ^^^^ programming language and compiled into a platform- 
manufacturer CMS virtual machine 24 downloads a schema independent form. 

validation program 140 to the user CMS lOU, the user 9. The system of claim 4 wherein the virtual machine has 

provides component specifications 142, and component 40 a hybrid architecnire that implements registers as locations 

database information 144 is downloaded to the user CMS in a virtual machine stack. 

lOU. Once a component has been selected and validated by 10. The system of claim 1 wherein the kernel includes an 

the schema validation program 140, the selected component object/persistence manager responsible for allocation, 

146 is downloaded and inserted into the model 16 on the references, and persistence of all objects in the model, 

user CMS lOU. 45 11. The system of claim 1 wherein the framework is 

From the foregoing description, it can be seen that the written in a platform-independent programming language 

present invention comprises a new and useful computerized and compiled. 

modeling system. It will be appreciated by those skilled in 12. The system of claim 11 wherein the framework is 

the art that changes could be made to the embodiment ^rftten in a platform-independent object-oriented schema 

descnbed above without departing from the broad inventive 50 implementation programming language and compHed, 

concepts thereof. It is understood therefore, that this rnven- 13 Tfa, ^^^^ ^ ^^^^^^ ^^^^^ ^ ^^^^^ 

Uon IS no limited to the partiailar embodm^ent disclosed ^ phtform-independent object-oriented schema imple- 

but It IS mtended to cover modifications within the spirit and ... 1 1 1 1 • / 

scope of the present invention as defined by the appended T ' P™8"=""'°g '^°g»*8e and compUed «ito a 

claims ^ rr platform-independent form. 

What is claimed is* ^® system of claim 1 further comprising a system 

1. A computerized modeling system (CMS) for construct- ^^^^^ ^y-*^^^"^ '^^^^ ^^^^^ information for the 

ing a portable persistent model from persistent component framework, the system stale object being created when the 

objects and for persistently saving and recalling at least one framework is initially executed and being a known point for 

subset of the portable constructed model, each component eo queries to determine a current state of the framework, 

object including an object and its corresponding class, the system of claim 14 wherein the system state 

system composing: object holds a reference to an object representative of the 

a first platform for providing system-dependent services, model, 

the first platform being one of a plurality of different 16. The system of claim 14 wherein the system state 

platforms, each platform including an operating system as object holds a reference to an event responder, the event 

and computer hardware which executes the operating responder being executed in response to an occurrence of a 

system; specific event triggered by the CMS user. 
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17. The system of claim 14 wherein the system state 
object holds a reference to a window, the window being 
employed as an interactive interface between the CMS and 
the CMS user. 

18. The system of claim 1 wherein the framework 5 
includes a command tool manager for accessing a set of 
command tools and for manipulating the model with the 
command tools. 

19. The system of claim 1 wherein a transaction is a series 

of modifications to objects in the model, and wherein the lo 
CMS further comprises a transaction manager for tracking 
each persistent component object involved in a transaction 
and for maintaining a copy of each such persistent compo- 
nent object prior to the transaction, the transaction manager 
also for undoing a transaction. 15 

20. The system of claim 19 wherein the framework 
includes the transaction manager. 

21. The system of claim 1 wherein the framework 
includes a portable graphical user interface (GUI) tool kit 
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having a set of GUI tools, the set of GUI tools being 
independent of the platform. 

22. The system of claim 1 wherein the project database 
has a plurality of persistent stores, each persistent compo- 
nent object in the portable persistent model being instanti- 
ated from a schema and being stored in one of the persistent 
stores with one schema. 

23. The system of claim 22 wherein the project database 
has a plurality of persistent stores, each persistent compo- 
nent object in the portable persistent model being instanti- 
ated from one of a plurality of schemas and being stored in 
one of the persistent stores with the instantiated-from 
schema. 

24. The system of claim 23 wherein the schemas are 
selected from a group consisting of a project schema, a 
modeling schema, a drafting schema, a compatibility 
schema, and a discipline -specific schema. 
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